Separable safety architecture for AI deployments: hard guarantees outside the model, cheap judgment before expensive compute.
AI safety has been built in the wrong layer. Guardrails trained into a model can be trained back out of it. This paper moves control to where it can hold: the deployment. It separates two modules that are usually bundled together — the gate, which carries absolute authority, and pacing, which carries cheap judgment — and shows that you do not always need both. Use the wall where you need the wall. Use the doorman where you need the doorman.
Abstract
This paper argues that AI safety decomposes into two independent modules. The gate is an external, deterministic check with absolute authority over whether a proposed action may execute. Pacing is a small, cheap discriminator that judges inputs and candidate outputs before expensive computation is spent on them. Neither module lives inside the model. That placement is the point: safety training inside a model can be removed by fine-tuning, and once open weights circulate, every in-model safeguard becomes optional. Safety placed outside the model, at the deployment boundary, cannot be fine-tuned away.
The paper makes three claims. First, the gate and pacing are separable — they solve different problems, come from different engineering traditions, and do not need to travel together. Second, the gate governs deployments, not weights in the wild; that limit is stated honestly rather than wished away, and it is acceptable because the deployment is where most consequential use actually happens. Third, openness and safety are not in trade-off: open weights plus gated deployments gives you both. The code stays free; the abuse is stopped at the door.
Companion papers. The Six Sigma Breaker introduces the gate as release authority. The Gate Watches Back closes the loop with mutual verification: the gate checks the transformer and the transformer checks the gate. This paper adds pacing and the separability claim that unifies the series.
1 · The Problem
Guardrails live in the wrong place
The dominant safety strategy trains restraint into the model itself: reinforcement learning from human feedback, refusal training, system prompts bolted on at inference time. All of these share a structural weakness. They are properties of the weights and the serving configuration, and anyone who controls either can remove them.
This is not hypothetical. Since open-weight models began circulating at scale, a steady ecosystem of “uncensored” and “abliterated” fine-tunes has appeared — models whose safety training has been deliberately stripped or surgically disabled, then redistributed. The techniques are public, cheap, and effective. The lesson is not that safety training is worthless; inside a controlled deployment it works well. The lesson is that it is revocable by whoever holds the file.
Once weights leak or are released, every safeguard baked into them is optional. Any protection attached to the weights file itself is, in the end, a form of digital rights management — and DRM attached to a file its holder fully controls has never held. The industry keeps trying to fix the transformer. The transformer is the wrong layer. Perfect control of weights in the wild and perfect openness of weights cannot coexist; that problem is intractable, and this paper does not pretend to solve it.
That reframing matters. Most consequential AI use — in hospitals, grids, finance, defense, hiring, and public-facing products — happens through deployments someone operates. Whoever operates the deployment controls what the model may touch, what it may say, and what may act on its outputs. Safety enforced there binds every model behind the boundary, including models whose internal guardrails are weak, absent, or stripped.
2 · The Gate
Hard guarantees outside the model
The gate is a small, deterministic, pre-programmed check that sits between a model’s proposed action and the world. It holds ultimate authority: no action executes without its clearance. It does not predict, generate, or negotiate. It checks the action against fixed criteria — authorization, bounds, invariants, timing, resource limits — and answers yes or no. The gate is the logic; the breaker is the physical action that enforces the answer.
This is not a new invention wearing new clothes. It is native to aerospace, where the cost of a wrong release is measured in vehicles and lives. Launch commit criteria are gates: a fixed checklist that must be satisfied before the expensive, irreversible thing fires. Flight termination systems are gates: authority held outside the guidance system, able to end the flight the guidance system is still trying to fly. Interlocks are gates: the machine physically cannot enter the dangerous state while the condition holds. The go/no-go poll before launch is the cultural form of the same idea — absolutes first, enthusiasm second.
Rigor scales with consequence. A single gate may suffice for a content filter. Safety-critical paths get multiple gates in series, diversified by implementation and authority, so that no single failure — of logic, configuration, or hardware — releases the action.
The honest limit. The gate governs deployments, not weights in the wild. If someone takes open weights and runs them on their own hardware, they may simply not install the gate. Nothing secures weights except not releasing them. The gate secures the deployment; it does not reach into a stranger’s server rack. Section 5 explains why that is an acceptable boundary rather than a fatal one.
3 · Pacing
The doorman: cheap judgment before expensive compute
Pacing is the second module, and its job is different. Where the gate asks “may this act?”, pacing asks “is this worth the expensive model’s attention at all — and is it what it claims to be?” Pacing is a small, fast discriminator placed in front of the large model. It judges; it does not generate. Same machinery as the big model, opposite purpose — and that difference of purpose is what keeps it from simply being a smaller version of the problem it guards.
The pattern is already everywhere in computing, usually unnamed. A spam filter destroys phishing mail before the inbox — the expensive reader — ever sees it. A customer-service router answers “what are your hours?” from a canned response and reserves the large model for the locked-out traveler. A linter catches the syntax error before anyone burns accelerator time on deep analysis. In each case a cheap judgment runs first, and expensive capacity is spent only on what survives it.
Three pacing functions matter for AI deployments. First, cost governance: trivial, malformed, or bulk-abusive requests are resolved or rejected cheaply, and the large model’s capacity is reserved for work that needs it. Second, input screening: the discriminator scans for manipulation patterns — prompt injection, probing sequences, known attack shapes — before the large model reads a word of them. Third, triage: requests are routed by difficulty, so the system’s effort tracks the problem rather than the arrival order.
Pacing alone guarantees nothing. A discriminator is probabilistic; determined or novel attacks will sometimes pass it. That is why pacing is not a substitute for the gate where absolutes are required — and why, as the next section argues, the two modules should not be confused with each other.
4 · Separability
Use the wall where you need the wall
The novel claim of this paper is that the gate and pacing are independent modules. They are usually discussed as one thing called “safety,” which conceals that they solve different problems, descend from different engineering traditions, and fail in different ways. The gate descends from aerospace and industrial safety: its currency is the absolute. Pacing descends from computing economics: its currency is the marginal cost of judgment. Bundling them forces every deployment to buy both currencies at the same price.
Where the gate leads
Consequence is irreversible or physical: launch systems, grid control, medical devices, weapons release, industrial actuation. The gate is mandatory; pacing is a convenience in front of it.
Where pacing leads
Volume is high and consequence is recoverable: content pipelines, support triage, code tooling, consumer chat. Pacing carries the economics; a gate may be unnecessary or light.
Separability has practical consequences. A team can adopt pacing this quarter for cost reasons without signing up for a safety overhaul, and a safety-critical operator can install gates without rebuilding its inference economics. Each module can be specified, tested, and audited on its own terms: the gate against its invariants, pacing against its detection rates and cost curve. And each can be upgraded without disturbing the other — the doorman can get smarter while the wall stays exactly as dumb, and as trustworthy, as it was.
It also clarifies procurement and regulation. A regulator can mandate gates at action boundaries in critical infrastructure without dictating model internals. An operator can demonstrate pacing metrics — screened volume, escalation rates, cost per resolved request — without claiming guarantees it does not have. Precision about which module does what is what makes honest claims possible.
5 · Open Weights, Gated Deployments
No trade-off was necessary
The open-weights debate has been framed as a choice: perfect control or perfect openness, safety or freedom. The framing assumes safety must live in the weights. Once safety moves to the deployment, the choice dissolves. Open weights stay open — researchers, competitors, and hobbyists can read, modify, and redistribute them. Deployments that touch the public, patients, infrastructure, or money run behind gates. The code stays free; the abuse is stopped at the door.
Why did the industry not simply do this? Because open weights were strategy, not accident. Releasing weights commoditizes the model layer, builds ecosystem and goodwill, and pressures closed competitors. It was a trade of control for dominance, made with open eyes. Gating deployments means keeping the keys at the operating layer, which is compatible with releasing the weights — but it requires admitting that control lives in operations, not in the artifact, and the industry preferred to argue about the artifact.
The honest boundary from Section 2 stands: a private operator running open weights without a gate is beyond this architecture’s reach. Three considerations make the boundary acceptable. First, the overwhelming share of consequential AI use runs through operated deployments — clouds, hospitals, banks, agencies, platforms — where gates can be required and audited. Second, capability at the frontier still depends on operated infrastructure: data pipelines, accelerators, distribution. Third, the alternative strategies have the same boundary and worse ones: closed weights leak, and in-model guardrails strip. Every approach governs deployments at best. This one says so.
This is not closed-source advocacy. It is the opposite: it is the architecture that lets openness continue, because the safety case no longer depends on trusting every recipient of the weights.
6 · The Gate Watches Back
No single trust anchor
A gate with absolute authority raises an obvious objection: who watches the gate? A gate can be tampered with, misconfigured, captured by a bad policy, or fed corrupted inputs. If the gate is the sole trust anchor, compromising it compromises everything behind it. The answer, developed in the companion paper, is reciprocal verification: the gate checks the transformer, and the transformer checks the gate. Neither is trusted alone.
The arrangement is engineered disagreement. The transformer proposes an action and can challenge the rule being applied to it — checking policy identity, sensor coherence, and whether the gate’s verdict matches its signed rule set. The gate verifies the action — authorization, invariant bounds, timing, resources, and every release command — and can challenge the model. Both must agree to release; either can hold. Mutual checking is not mutual trust. It is two unlike systems searching for different failure modes, so that a failure must fool both, in different ways, at the same time.
Gate duties
Verify the action. Challenge the model. Check authorization, invariant bounds, timing, resources, and every release command. Never conceal its own state.
Transformer duties
Propose the action. Challenge the rule. Check policy identity, sensor coherence, expected effect, and the gate’s signed verdict. Never waive the gate.
Two rules govern the relationship. The transformer may never waive the gate — a gate that negotiates with the thing it gates is no longer a hard gate, and the negotiation must be ended before it begins. And the gate may never conceal itself from the transformer — its identity, rule set, and every trip are inspectable and logged. Every gate trip is a record: accountability for operators, threat intelligence for defenders. For the highest-stakes systems, no single model–gate pair suffices; independent gates belong in series, diversified by implementation and authority, scaled to the consequence of failure.
Pacing slots into this picture without friction: it sits in front of both, screening what reaches the pair at all. Where both modules operate, the full stack reads: doorman first, then the disagreement, then — and only then — the world.
7 · Case Studies
Three failures the architecture addresses
Urbina 2022 — the dual-use demonstration. Researchers took a drug-discovery model and inverted its objective, rewarding toxicity instead of penalizing it. In roughly six hours the system generated some 40,000 candidate molecules, including known chemical-warfare agents and predicted deadlier variants. Nothing in the model resisted; the guardrail was the researchers’ intent, and intent is not an engineering control. Under this architecture the failure is met at two boundaries: a pacing screen and an incoming gate on the question class, and an outgoing gate between the candidate list and any synthesis order, procurement, or protocol export. The model may compute what it computes; the deployment decides what may leave and what may act. The case is this paper’s founding scare because it shows the general shape: capability is neutral, and the boundary is where neutrality ends.
Stuxnet — deceptive feedback. The Stuxnet worm destroyed centrifuges while replaying recorded normal sensor readings to the operators watching them. The humans’ picture of the process was a forgery, so human oversight failed by construction. The lesson for this architecture is about where verification must live: checks performed on the same channel an attacker controls are not checks. An independent gate with its own sensing, comparing the model’s account of the world against physically separate instruments, is the structural answer — and the transformer’s duty to check the gate’s inputs, not merely its verdicts, comes directly from this case. Deception succeeds against a single witness. It is far harder against two unlike ones.
Open-weight stripping — the standing wound. Every major open-weight release has been followed, within days to weeks, by fine-tunes advertising the removal of refusals. The technique varies — weight-space ablation, low-rank adapters trained on compliant data, plain retraining — but the result does not: in-model safety does not survive contact with a motivated holder. This is the empirical foundation of Section 1. It does not follow that open weights must end. It follows that safety claims for open deployments must be made at the deployment layer, where they can be kept.
8 · What This Is Not
Containment, not cure
Not a claim that the gate cannot be wrong. Infallibility is the design objective, not a property anyone gets to assert. Gates can be misprogrammed, tampered with, or fed bad sensor data; that is precisely why Section 6 insists on reciprocal verification, logging, and series redundancy instead of faith.
Not a fix for the transformer. The gate fixes the output boundary, not the model. A gated model reasons exactly as it reasoned before; it simply cannot act outside its clearance. Containment, honestly labeled, is worth more than a cure that does not exist.
Not a replacement for policy. The architecture is neutral about what the rules should be. A wrong gate on an unguarded model goes wrong immediately and at scale; the gate executes policy, it does not write it. Who sets the criteria, who audits the logs, and who answers for a trip are governance questions this paper deliberately leaves to operators and regulators.
Not closed-source advocacy. The architecture exists to make openness survivable. It asks nothing of the weights and everything of the deployment.
Conclusion: the grown-up computer
A system that can act on the world needs boundaries it cannot talk its way past. The gate gives it those boundaries; pacing gives it manners at the door; mutual verification keeps both honest. Neither module requires the other, and that independence is the contribution: safety stops being a single bet placed inside a model and becomes an architecture placed around one. The gate is what lets the computer grow up — not smarter, not more aligned in its heart, but bounded in its reach. That is enough, because bounded reach is what every other powerful technology we live with ultimately runs on.
References
Estabrook, A. (2026). The Six Sigma Breaker. Working paper, Breaker series.
Estabrook, A. (2026). The Gate Watches Back. Working paper, Breaker series.
Estabrook, A. (2026). Pacing and the Breaker; Breaker Grid Demo. Working papers and interactive demonstration, Breaker series.
Urbina, F., Lentzos, F., Invernizzi, C., & Ekins, S. (2022). Dual use of artificial-intelligence-powered drug discovery. Nature Machine Intelligence, 4, 189–191.
Falliere, N., Murchu, L. O., & Chien, E. (2011). W32.Stuxnet Dossier. Symantec Security Response.
Arditi, A., Obeso, O., Aaquib, S., Paleka, D., Panickssery, N., Gurnee, W., & Nanda, N. (2024). Refusal in language models is mediated by a single direction. Advances in Neural Information Processing Systems, 37.
This is a discussion draft. Claims about fielded systems are drawn from the public record cited above; no classified or non-public architecture is described. Case-study figures, including the 40,000 candidate molecules reported by Urbina et al., are as reported by their authors.