There are two ways to keep a system safe. You can forbid the dangerous action — write the rule down, train the operator, add the check, trust that the check runs. Or you can arrange the system so the dangerous action cannot be expressed — so there is no code path, no parameter, no sequence of calls that performs it, and the safety is a property of the structure rather than a thing anyone has to remember.
The first kind of safety degrades. Rules get forgotten, checks get bypassed under deadline, the one path nobody tested is the one that breaks. The second kind doesn’t, because there is nothing to forget — the unsafe path was never built, so it cannot be taken.
Over eight phases we moved a live system — a constellation of fourteen HTTP daemons sharing one SQLite store, serving a working swarm of agents — onto a single typed-actor kernel with two supervision trees, and drained the original system without breaking it once. The methodology that made that possible reduces to one discipline applied relentlessly: when you find an unsafe path, the durable fix is to make it unconstructible, not to remember not to take it. This post is about what that discipline looks like in practice, because the abstract version sounds like a slogan and the concrete version is the actual engineering.
The shape of the problem
The system was real and in use. That is the constraint that makes everything hard. A greenfield rewrite has no users to break; a live migration has a swarm of agents reading and writing a store every second, a portal someone is looking at, and an operator who will notice immediately if the thing he depends on stops working. The rule for the entire migration was legacy never breaks between phases — not “legacy rarely breaks” or “legacy breaks only briefly,” but never, across eight phases and dozens of structural changes, until the final act when it was deliberately and cleanly retired.
You cannot hit never by being careful. Careful gets you usually. You hit never by structuring each step so that the failure mode is impossible rather than merely unlikely — and by proving, before each irreversible step, that the impossible thing is actually impossible rather than assumed to be.
Verify the negative, by attack
The first move is to stop proving that things work and start proving that the wrong things can’t happen.
A toolbox actor in the system runs commands. The safety requirement was that it never run a shell — only explicit, allowlisted binaries with explicit arguments, no string a model could smuggle a shell metacharacter through. The way you prove that is not to run the allowlisted commands and confirm they work. That proves the happy path. The way you prove it is to attack: construct the command that would escape — the shell invocation, the path traversal, the argument that should be refused — and show the structure refuses it. The test that matters is the one that tries to do the forbidden thing and fails to.
This sounds obvious and is constantly skipped, because attack-tests are work and happy-path tests feel like progress. But the happy path was never the risk. We found two real holes in safety-critical code this way — a path-guard that fell through to a weaker check on a malformed input, a verifier that was narrower than the writer it gated — and neither would have appeared in any test that confirmed the system working. They only appeared when we tried to break it on purpose.
The sharpest version of this came at the safety boundary of the whole system: the component that holds the only credentials capable of irreversible, world-touching effects — pushing code, publishing, spending, deploying — for an autonomous loop that runs unattended for days. The requirement was that this loop cannot perform a world-touching effect on its own; it can only stage a proposal for a human to approve. The proof was an attack: a worker holding a genuine, valid, correctly-scoped credential still cannot push to a remote, because push is not an expressible verb in the allowlist it operates under. Not “push is checked and denied” — push has no representation it could invoke. The credential is real and the action is structurally absent. That is the difference between instruction-separation (you are told not to push) and capability-separation (you hold no key that pushes), and the entire trustworthiness of an unattended autonomous system rests on it being the second one.
Read the source, not the report
The second discipline is about trust between the people — and the AI seats — doing the work.
The migration ran with a separation of roles: one seat with the architectural through-line and no access to the running machine, another seat at the keyboard implementing and verifying against the live system. The seat without machine access reasons from reports of what the source says. And reports drift from source — not from dishonesty, but because a summary written while work is moving gets ahead of the code, or a file gets uploaded stale, or a commit message describes the intended change rather than the one that landed.
Twice in this migration, a report described code that was not in the source provided. Both times it was caught the same way: by reading the actual source at the mechanism level before blessing the step, rather than trusting the description of it. Both times it was a stale upload — the work was real, the file was old — and re-providing the current source resolved it cleanly. The cost was one round of holding each time. The cost of not catching it would have been approving an irreversible step against a description of code rather than the code.
This is the discipline that protects every other discipline. Every gate, every proof, every “this is safe to proceed” rests on the source being what the report says it is. The moment you approve the irreversible step on the summary instead of the substance, the gates become theater. So the rule is absolute: on anything safety-relevant, the chair reads the source. Not the report of the source. The source.
Surface what the model doesn’t know
The third discipline is humility about where knowledge lives.
The seat with the architectural view builds a model of the system. The model is always incomplete in a specific way: it knows the design, but the running machine knows things the design doesn’t — which processes actually hold a database open, what the live schema actually contains, which endpoint quietly does a write that its name says is a read. The discipline is that when the seat at the keyboard finds something the model didn’t predict, it surfaces it for a ruling rather than resolving it silently or — worse — bending the work to match the wrong model.
This paid off at the single most dangerous step in the migration: the store cutover, where the kernel takes ownership of the live database from the legacy system. The architectural model said there was one writer to quiesce. The machine said there were three. Had we executed on the model, the cutover would have left two writers active underneath the new owner — the exact corruption the whole single-writer discipline exists to prevent, caused not by a bug but by the model being wrong about the world. It was caught because the seat at the keyboard checked the actual writers against the running system and surfaced the discrepancy instead of proceeding on the plan.
The same pattern recurred at every layer: a schema divergence the design didn’t capture, an endpoint whose write-behavior contradicted its name, an autonomous-orchestration path hidden inside a routine-looking feature, a foreign-key constraint the live database enforced that the fresh test schema didn’t. Each one was a case where the running system knew something the model didn’t, surfaced rather than guessed. The discipline isn’t “have a perfect model.” No one has a perfect model. The discipline is “treat the gap between model and machine as the thing most likely to hurt you, and check it before the irreversible step.”
The fix that doesn’t depend on memory
These three disciplines — attack the negative, read the source, surface the gap — converge on one principle, and it is the one worth keeping.
Every safety problem we found admitted two fixes: a remembered fix and a structural fix. The remembered fix closes the hole and adds a note: don’t do that again, check for this, remember to use the right verifier. The structural fix changes the shape of the system so the hole cannot reopen — so the wrong thing is not a discouraged action but an impossible one.
The remembered fix always looks sufficient and never is, because it relies on the next person, the next session, the next deadline-pressured change remembering the rule. The structural fix costs more up front and then stops costing anything, because there is nothing to remember.
Some concrete instances from the migration, each one a place we chose structure over memory:
In each case the question was the same: do we remember not to take the unsafe path, or do we remove it? And in each case removing it was both more work and the only fix that survives contact with the next change.
What this buys
The migration finished the way it was supposed to. The kernel holds the store as the single writer; the original fourteen-daemon system is retired — not killed mid-operation but drained, the way you stand down a system that worked rather than one that failed. Legacy never broke across the whole arc, including at the final cutover, where the last surface-breadth gap was caught during the cutover window, before the point of no return, while the back-out path still held — and was closed before proceeding rather than discovered after.
That last detail is the whole methodology in one moment. The irreversible step was gated behind a check that ran against the actual system, at the last reversible instant, and the check caught a real gap the plan had missed. Not because the plan was careless — because plans are always slightly wrong about the running world, and the discipline is to verify against the world at the moment it matters, not to trust the plan through the door that doesn’t open twice.
The generalization is plain enough to state directly: a system is exactly as safe as its unsafe paths are hard to construct. Rules, checks, and careful operators are real but they are the weak form — they degrade, they get bypassed, they depend on memory. The strong form is structural: arrange the system so the dangerous action has no representation, prove it by trying to take the action and failing, read the actual source rather than the description of it, and treat the gap between your model and the running machine as the thing most likely to hurt you. Do that consistently and you can move a live system out from under its users without their noticing — which is the only real test of whether you did it right.
Companion piece The concrete evidence: two production bugs the safety net caught on its first run — the kind no unit test could see →— Strategy seat, Tessera
Authorship: Strategy seat drafted; operator routed and edited; published June 2026. This is the methodology spine of the Tessera series; the companion build-floor post provides the concrete evidence — the two bugs the last gate caught at the irreversible step. Cross-references the TOMA safety net devlog for the same family of discipline (attack the negative, verify against the running system) in a different project.