Wiring the organisms together

audience: operators

Each organism is standalone; the lattice emerges from how they subscribe to each other’s public surfaces. This page is the operator-level view of that wiring: what flows where, what the per-organism driver expects to see upstream, and what happens operationally when something is not flowing.

The contributor-level version of this page is composition; the subscription graph is identical. This page drops the state-machine jargon and names the knobs you actually tune.

The pipeline at a glance

  integrators ─► zipnet ─► unseal ─► offer ─► atelier ─► relay ─► tally ─► integrators
                                      ▲          ▲
                                      │          │
  integrators ──────────────────► offer (bids)   │
                                  (searchers)    │
                                                 │
                                  on-chain inclusion watcher

Two integrator inputs (zipnet for wallets, offer for searchers), one integrator output (tally, for everyone). Every internal arrow is a mosaik collection subscription.

Who subscribes to whom

All subscriptions are on the shared universe. You do not configure subscription endpoints; the organism crates derive the upstream StreamId / StoreId from the lattice fingerprint each binary sees via LATTICE_CONFIG_HEX.

What “wired” looks like at runtime

For each organism, watch its *_upstream_peers metric. It reports how many peers the organism’s driver currently has a bond with on each upstream subscription. Values to expect:

• unseal_upstream_peers{source="zipnet::Broadcasts"} — at least 3 (a zipnet committee member).
• offer_upstream_peers{source="unseal::UnsealedPool"} — at least 3.
• atelier_upstream_peers{source=...} — same for each of its two upstreams.
• relay_upstream_peers{source="atelier::Candidates"} — at least 3.
• tally_upstream_peers{source=...} — at least 3 per source.

A zero on any of these means the organism is not yet bonded upstream; it is a transient state during bring-up and an incident during steady state. See Incident response — missing upstream.

The slot is the foreign key

Every commit in every organism is keyed by the chain’s slot number. Operators rely on this to debug the pipeline end to end: pick a slot, query each organism’s collection for that slot, and check the chain one stops at.

slot 21_000_000
  zipnet::Broadcasts[21_000_000]          committed ✓
  unseal::UnsealedPool[21_000_000]        committed ✓
  offer::AuctionOutcome[21_000_000]       committed ✓
  atelier::Candidates[21_000_000]         committed ✓
  relay::AcceptedHeaders[21_000_000]      committed ✓
  tally::Refunds[21_000_000]              pending (awaiting on-chain inclusion)

Walking the pipeline slot-by-slot is the first debug step for every “something is stuck” incident.

Cross-organism secrets

Nothing about one organism’s committee secret lets a holder join another organism’s committee. The secrets are disjoint. This is by design: a compromised offer member does not taint atelier.

The one shared piece of identity is the lattice’s LATTICE_CONFIG_HEX, which every process reads; it is a public fingerprint, not a secret.

Running fewer than six organisms

Not a supported shape. A partial lattice is not a lattice. If you want to run zipnet only, deploy the zipnet organism standalone (that is what the zipnet book covers). If you want the full pipeline, run all six.

The only “skip an organism” posture that makes sense is to adopt someone else’s deployment of that organism — e.g. use the foundation’s reference unseal instead of running your own. This is a commercial agreement between you and that operator, not a protocol feature. In a lattice, every organism’s identity is compiled into the LatticeConfig; there is no runtime routing that picks one provider over another.

Cross-references

• Lattice overview
• Quickstart — stand up a lattice
• composition.md — the same graph with state-machine semantics.