Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

What you need from the coalition operator

audience: integrators

Before compiling a CoalitionConfig into an agent, the integrator requires a short item list from the coalition operator plus a pair of sanity checks. This page is the checklist.

The eight items

  1. The CoalitionConfig definition. Either a Rust const declaration pasted into the integrator crate, or a serialised fingerprint (hex of coalition_id()) paired with the integrator’s own copy of the struct definition.

  2. Every included LatticeConfig. Typically pulled by reference from each lattice operator’s handshake page. The coalition operator should publish a per-coalition table listing the referenced lattices and a link to each lattice operator’s release notes.

  3. Every included standalone-organism reference. For each organism the coalition composes outside a lattice, the coalition operator publishes the role name, the organism’s stable id, the optional content hash if pinned, and a link to that organism’s own handshake page.

  4. Every referenced confluence’s ConfluenceConfig. Confluences are coalition-independent; each carries a link to its own operator’s handshake page.

  5. Every shipped module’s ConfluenceConfig. Atlas, Almanac, Chronicle — whichever the coalition ships. Modules not shipped are stated explicitly; silence is ambiguous.

  6. MR_TDs for every TDX-gated unit the coalition operator commissions — modules, coalition-run confluences, and standalone organisms they run. (Per- citizen MR_TDs come from the per-citizen operators; the coalition operator re-publishes for convenience.)

  7. At least one initial peer hint for the shared universe (cold-start bootstrap). Typically the same hint every mosaik service uses; re-published for convenience.

  8. A change channel. The mechanism through which the coalition operator notifies of a referenced citizen’s stable-id bump or a referenced confluence’s Config change.

Coalition operators do not issue per-citizen tickets; those come from per-citizen operators. A coalition may publish its own optional ticket issuer; components and integrators choose whether to recognise it.

Verification

Perform two sanity checks once the items above are in hand.

Fingerprint round-trip

Compile the pasted CoalitionConfig. Call coalition_id() on it. Compare to the operator’s published fingerprint. Both must match byte-for-byte. A mismatch means the struct definition drifted or the serialiser differs; do not proceed until the mismatch resolves.

Citizen reference cross-check

For each referenced LatticeConfig, call stable_id() and compare to the lattice operator’s published stable id. For each referenced standalone organism, compare the OrganismRef stable id (and content hash, if pinned) to the organism operator’s published one. A mismatch means the coalition operator’s copy drifted from the per- citizen operator’s. Request an updated CoalitionConfig.

Trust

Nothing in the coalition operator’s handshake is cryptographically authoritative: a coalition fingerprint names a composition, it does not sign it. The checks above suffice because the identity work is done at the per- citizen rung. The coalition layer stitches known fingerprints together and adds a small catalog of modules.

Cross-references