Federation

The governance layer for a multi-node Claude system

On May 21, 2026, a Claude session running inside the brainstorm node wrote a file. The write succeeded. Nothing about it looked unusual from inside the session. The bytes landed in the general-purpose node, several directories away from where the brainstorm node lives. No error surfaced anywhere in the run. Two days passed before anyone noticed — when someone opened the general-purpose node for an unrelated reason, scanned its contents, and stopped on a file whose name belonged to a different project entirely.

The relocation was not a bug in Claude. It was the predictable result of a system built outward — more nodes, busier sessions, growing volumes of cross-node work — without ever building the controls that keep nodes apart. Seven specific controls were missing. The session had no declared identity. No route map existed. No router stamped each session with its home. No task envelope carried an origin field. No behavioral rules said writing outside the home node was out of scope. No health checks ran. No audit tool existed to flag a stray file. Any single survivor among those seven would have shortened a two-day silence to a same-day catch.

This book builds all six artifacts — the governance layer that Book 4 introduced but did not fully cover — across six chapters, each producing one working component you can adapt to a real system.

Six artifacts from node identity to health checker

• node-identity — The node registry: a registry.json file that assigns every node a stable kebab-case identifier, a declared root path, and the properties routing machinery reads at runtime. Why a node that cannot say what it is gives every later control nothing to check against, and why the identifier is immutable after the node goes live.
• the-route-map — The route map: a declarative file that records which nodes may dispatch to which other nodes, fails closed when a route is missing, and gives audit logs a canonical record to compare actual dispatches against. The distinction between a route that is permitted, one that is not listed, and one that is explicitly forbidden.
• the-router — The session router: the component that reads the registry at session start, stamps the session with its home node, and checks every dispatch against the route map before it goes through. How the router turns a declarative route map into enforced behavior, and what it logs when a route check fails.
• cross-node-dispatch — The task envelope schema: the structured format that makes cross-node work auditable by requiring an origin field, a destination field, and an intent statement before any task crosses a boundary. The difference between a task that arrived as a loose instruction and one that arrived as a signed envelope.
• behavioral-governance — The governance rule set: the behavioral instructions that close the gaps technical controls leave open. What sessions are permitted to write, permitted to read, required to record, and required to refuse. How rules interact with the router and envelope schema to create a layered defense rather than a single point of failure.
• operating-at-scale — The health checker: a script that walks every node, reads each file’s path, and compares it against the registry to flag any file sitting outside the node that owns it. How to run it on a schedule, what a clean report looks like, and how to investigate a stray-file finding before removing it.

A preview

Notice how the seven divide. Identity, the route map, and the router are declarative — they state what each node is and what it may reach, and they fail closed only if something reads and enforces them. A federation needs all three kinds at once. Declarations without enforcement are documentation; enforcement without a catch-net trusts that you wrote every rule correctly the first time.

Each of those seven absences was reasonable in isolation. Nobody sits down to build a fifteen-node system; you build one node, then a second when the first gets crowded, and the boundary controls are exactly the work that feels premature until the morning a file turns up where it should not be.

Claude Code users running multi-node systems

This book is for Claude Code users who run work across multiple nodes — separate projects, contexts, and domains — and want enforced boundaries between them rather than boundaries that depend on everyone remembering the rules. It builds on Book 4, which introduced the concept of a node and a basic federation config. This book builds the governance layer Book 4 did not cover: the registry, the route map, the router, the task envelope, the behavioral rules, and the health tooling that make a multi-node system safe to operate when the stakes of getting it wrong are real. Every artifact is drawn from a live fifteen-node system and shown complete.

A longer excerpt is available to newsletter subscribers.

Buy Ebook on Amazon