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
-
The
CoalitionConfigdefinition. Either a Rustconstdeclaration pasted into the integrator crate, or a serialised fingerprint (hex ofcoalition_id()) paired with the integrator’s own copy of the struct definition. -
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. -
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.
-
Every referenced confluence’s
ConfluenceConfig. Confluences are coalition-independent; each carries a link to its own operator’s handshake page. -
Every shipped module’s
ConfluenceConfig. Atlas, Almanac, Chronicle — whichever the coalition ships. Modules not shipped are stated explicitly; silence is ambiguous. -
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.)
-
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.
-
A change channel. The mechanism through which the coalition operator notifies of a referenced citizen’s stable-id bump or a referenced confluence’s
Configchange.
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.