Each joining machine is a governed MIDI2 instrument
MIDI2 is the precondition. A machine joins the estate only after its named instrument proves identity, capability, readiness, and lifecycle.
The decision
A machine is not eligible because it answers on an IP address, appears in Bonjour, accepts SSH, or has a familiar local name. It becomes eligible only when a named native MIDI2 instrument on that machine has been admitted, started, and proven ready through the governed peer boundary.
EstatePublisher discovers and binds an already-admitted instrument. It does not silently choose or install an unknown bridge.
Simplicity and security
Chapter 143 governs the human-facing trust boundary: one owner bootstrap establishes one bounded session for the declared target, purpose, capabilities, effects, rollback, and expiry. Ordinary operation within that session produces no repeated Keychain, phone, broker, or second human-approval prompt.
A new owner decision is required only for expiry, revocation, rotation, recovery, scope expansion, or new-device enrollment. This removes duplicated ceremony without removing signed artifacts, target binding, authenticated identity, MIDI-CI readiness, least privilege, or FountainStore evidence.
The promotion path
- Select the named MIDI2 instrument contract and host adapter.
- Prepare the signed or pinned artifact with digest and source revision.
- Install and launch through the declared native adapter.
- Expose an authenticated MIDI2 peer and complete MIDI-CI capability exchange.
- Persist the signed identity, capabilities, endpoint, and lifecycle receipt in FountainStore.
- Hand the admitted identity to Chapter 140 for discovery, binding, enrollment, and cloud reconciliation.
Four authorities
| Question | Authority | Proof |
|---|---|---|
| What is the machine? | The named FCIS/MIDI2 instrument and host adapter | Signed identity, artifact digest, source revision |
| What can it speak? | The authenticated MIDI2 peer and MIDI-CI exchange | Typed readiness and declared capabilities |
| May it join? | FountainStore enrollment authority | Correlated Store receipt and authorization |
| What may it change? | EstatePublisher | Exact binding, typed operation, terminal read-back |
Admission predicates and refusal states
Admission is valid only when every predicate is observed in one correlated run.
| Predicate | Required proof | Refusal |
|---|---|---|
| Consent | One bounded owner bootstrap binds artifact, capabilities, effects, rollback, expiry, target scope, and idempotency; retries within that session do not prompt again | consent-unproven |
| Named instrument | Live catalog entry and matching kit/adapter contract | command-surface-insufficient or capability-seam-missing |
| Artifact | Signed/pinned release, digest, and source revision | artifact-unproven |
| Identity | Signed device/instrument identity bound to the target | identity-unproven or identity-mismatch |
| MIDI2 peer | Authenticated endpoint and typed readiness | midi2-not-ready |
| MIDI-CI | Required capability exchange and declared operations | midi-ci-incomplete |
| Store | Correlated FountainStore readiness receipt and read-back | readiness-unpersisted |
| Lifecycle | Start/restart/revoke behavior owned by the host adapter | lifecycle-unproven |
Refusal: the attempt stops safely on any missing, stale, ambiguous, unsigned, unauthenticated, or mismatched result; EstatePublisher does not bind, enroll, or mutate the network.
What does not establish instrument admission
IP presence, TCP/22, SSH configuration, DNS or mDNS, a host name, a process list, a listening socket, a Keychain item, a screenshot, an HTTP response, a shell exit status, or an uncorrelated MIDI packet is not admission proof.
The failed attempt produces a typed remediation request. The native path installs or repairs the exact missing component and retries under the existing bounded session. A new owner decision is required only when the remediation changes the trust boundary; it does not create a parallel bridge or password loop.
Machine-to-machine welcome contract
EstatePublisher treats the joining machine as a black box. It injects only the exact signed instrument artifact and launch contract declared by the one bounded bootstrap; it does not inspect, pre-seed, or infer the machine's internal Store, MUID, software revision, or device key.
The conceptual handshake is PROPOSED → CONSENTED → INSTALLED → IDENTIFIED → ADMITTED → ACTIVE. A failed attempt enters REMEDIATE and returns to PROPOSED; REVOKED remains terminal.
The bootstrap binds artifact digest, source revision, requested capabilities, resource/install effects, rollback identity, target scope, expiry, and idempotency. The machine's MIDI-CI instrument owns identity, discovery, profile inquiry, and readiness. EstatePublisher verifies the response, records and reads back one correlated FountainStore receipt, then continues toward admission.
This is the governing contract shape, not live acceptance evidence. An unmet gate drives the typed remediation loop rather than ending the membership effort; ordinary retries use the existing session without another prompt, while trust-boundary changes require explicit re-bootstrap.
Distribution and bootstrap source
The private Fountain Coach GitHub midi2-gpu-fabric repository is the distribution source for this joining-machine implementation. The public Fountain-Coach/midi2 repository remains the reusable MIDI2/MIDI-CI protocol dependency. EstatePublisher consumes a signed immutable release tuple from midi2-gpu-fabric: tag and commit, platform artifact, release manifest, public verification material, artifact digest, service entrypoint, and rollback metadata.
Read-only verification finds no published GitHub release for Fountain-Coach/midi2-gpu-fabric yet. The working tree contains the native daemon, signed release manifest, SecretStore-backed release signer, and EstatePublisher installation verifier, but the tuple has not been promoted to GitHub. Public Fountain-Coach/midi2 release v0.11.0 supplies the protocol foundation; it is not the joining-machine release.
The missing release surface is the next implementation slice: publish the signed joining-machine artifact and manifest from midi2-gpu-fabric; EstatePublisher verifies the pinned tag, commit, signature, and digest; the declared host adapter installs it; and the machine returns its MIDI2 readiness receipt.
Acceptance proof and DoD
Done means one bounded native acceptance run correlates the exact instrument contract, signed artifact and source revision, authenticated MIDI2 readiness, signed identity, MIDI-CI capabilities, FountainStore readiness write/read-back, EstatePublisher discovery-to-binding, and downstream enrollment, cloud reconciliation, publication, client, restart, and rollback receipts.
Until that proof exists, the machine is discovered or prepared, never admitted, and no local developer cloud installation claim may be made. The EstatePublisher path remains active: it diagnoses the missing predicate, proposes the smallest consented remediation, retries, and continues toward admission.
Relationship to Chapter 140
Chapter 140 governs EstatePublisher’s network topology mutation. This chapter is its machine-side precondition: make the machine a MIDI2 instrument first; then let EstatePublisher operate the admitted participant.
Current status: this is a governance and illustrated local projection. It does not claim that the current WLAN target has been promoted or enrolled.