OMNI saysEvery spawn and every retirement COMMITs a block to the per-user chain. Replaying it reconstructs the entire swarm — who ran, when, and what they produced.
The thread that ties the whole chapter together is the agent chain. A swarm is ephemeral — workers spawn and apoptose by the thousands — but its history is permanent because the conductor COMMITs a block at each lifecycle event: a SPAWN block when a worker is created (role, scope, budget, parent), and a RETIRE block when it ends (why it died, the signal it left). Between them sit the worker's own COMMITs (mol-67). Nothing about the swarm's life is off the record.
Because the chain is append-only and hash-linked, this record is a tool, not just a log. Replay it and you can answer any forensic question — which worker introduced a bad result (then ROLLBACK to before it, mol-70), how deep the spawn tree went, where the budget actually went. VERIFY can re-check old blocks; an auditor can confirm the swarm obeyed its rules without trusting the operator. The swarm is gone the instant it finishes, but the chain means you can always reconstruct exactly what it did.
Power-ups you unlock
A SPAWN block records role, scope, budget, parent at creation
A RETIRE block records why a worker died and the signal it left
Worker COMMITs (mol-67) sit between spawn and retire — full lifecycle
Append-only + hash-linked → replay answers any forensic question
Pairs with ROLLBACK (mol-70) and VERIFY: audit without trusting the operator
The Silent Failure attacks — common mistakes
Committing results but not spawns/retirements — the tree is unreconstructable
A mutable log instead of an append-only chain (cannot trust replay)
Forgetting the parent link, so the spawn tree cannot be rebuilt
Treating the chain as write-only logging instead of a queryable record
Boss battleEmit SPAWN and RETIRE blocks around a small swarm, then replay the chain to rebuild the full spawn tree and total the budget each worker consumed.