Guardrails
A Socratic walk-through of guardrails — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why wrap a deterministic check around a model that was already trained to behave?
Here is a complaint I hear often, and it is not a foolish one. A team spends months teaching a model not to leak secrets, not to abuse people, not to run the destructive command. Then, at deployment, someone bolts a twenty-line regular expression in front of it that refuses anything matching a credit-card pattern. It looks like an insult to the training — and worse, like theatre. If the model has been taught the rule, why restate it in code?
So let me ask the question underneath it: what exactly did the training give you? Not what did it teach — what did it give you, as a guarantee you could write down?
Reasoning it through
REASONING #Think about what training actually optimises. It adjusts weights so that, across an enormous sample of situations, the outputs a human would approve of become more probable. Notice the shape of that sentence: more probable. Nothing in the procedure ever produces the word "never". You end up with a system that behaves well on the distribution it was shaped against, and behaves in some unexamined way outside it.
That is not a slur on training — it is the only honest description of what a statistical fit can offer. And it means the failure rate is not zero but small and, crucially, unknown at the tails. If you serve ten million requests a day, a one-in-a-million failure is ten failures a day. Would you accept ten a day for the particular thing you are guarding?
Now consider the deterministic check. What does it give you that is different in kind? It gives you a property that holds by construction. A filter that refuses to transmit any string matching a private-key format does not "usually" refuse; it refuses. The check is dumber than the model in every way that matters for intelligence, and stronger than the model in the one way that matters for a guarantee.
Here is the step I would ask you to sit with. Two safeguards in a row only multiply their protection if their failure modes are independent. Put a language model in front of a language model to judge its output, and you have two components that can be fooled by the same strange input, because they share an architecture, a tokeniser, and often a training corpus. The clever check is not clever where you need it. So the value of the deterministic layer is not that it is better — it is that it fails for entirely unrelated reasons.
There is a second asymmetry worth noticing. For a great many properties, checking is far cheaper and more reliable than producing. Deciding whether a SQL statement is a SELECT is trivial; deciding what statement to write is not. Wherever that gap exists, you can put a cheap, total, verifiable check downstream of an expensive, capable, probabilistic generator — and take the strengths of both.
But what does this cost? Every deterministic rule has false positives. A regular expression for card numbers will eventually block a legitimate order reference. Does that change your view of where such a check belongs?
The analogy
THE ANALOGY #Think of an aircraft's landing gear. The pilots are trained, checklisted, and monitored, and the vast majority of gear-up landings are prevented by pilots simply doing their job. And yet the aircraft has a horn that sounds when the throttle is retarded below a threshold with the gear still up. The horn understands nothing about flying. It cannot recognise an unusual approach, a diversion, or an emergency — and it will sound sometimes when the crew are entirely correct. It is there because its ignorance is exactly what makes it dependable: no amount of workload, fatigue, or unusual circumstance changes what it does.
the horn only ever alerts a human who remains in command, whereas a software guardrail usually blocks the action outright, so a false positive is not a distraction to be dismissed but a legitimate request that silently fails.
Clarifying the model
THE MODEL #The point is not that deterministic beats probabilistic. It is that they cover different halves of the space, and you want the coverage, not the winner.
So a useful guardrail has three properties. It is independent of the thing it guards — different mechanism, different failure mode, ideally a different team's code. It is narrow — it enforces one crisply statable invariant, because a rule you can state crisply is a rule you can test, and a rule you can test is one you can trust. And it sits at a chokepoint where the consequential action actually happens: at the database connection, at the outbound HTTP client, at the payment call. A check on the model's intent is advisory; a check on the effector is enforcement.
Two misconceptions worth heading off. First, "guardrail" has come to cover both classifier-based content filters and hard-coded rules, and they are not equivalent — a classifier is another probabilistic model and inherits the problem above, so treat it as another layer, not as the floor. Second, there is a real hazard in this pattern that its advocates underplay: a visible guardrail can become the reason nobody fixes the underlying behaviour. If the filter catches the leak, the leak stops being an incident, and the model quietly keeps trying. Guardrails are only honest when what they block is also logged and counted, so the rate of near-misses stays visible.
And note what a guardrail cannot do. It cannot enforce anything you cannot specify. "Do not be manipulative" has no deterministic form; that one really does have to live in training, in evaluation, and in human oversight, and pretending a rule can carry it is worse than admitting it cannot.
A picture of it
THE PICTURE #How to readstart at the parallelogram where the model proposes something, and walk down the three diamonds in order — can the rule be stated, is the checker independent, does the action pass. The rounded node is the only exit where something actually happens; the flagged node on the right is the hazard the pattern creates rather than solves, which is why the blocking path loops through logging.
What became clearer
WHAT CLEARED #Training buys you good behaviour on average; a deterministic check buys you one narrow guarantee that does not degrade with novelty. Neither is redundant with the other, because their failures are uncorrelated — and that uncorrelatedness, not cleverness, is the entire product. The design question is therefore never "is the model good enough yet?" but "which of my invariants can be stated exactly, and where in the pipeline can I enforce them?"
Where to go next
ONWARD #- Signal detection: how to choose a filter's threshold when false positives and false negatives cost different amounts.
- The dual-LLM and capability-restriction patterns, which apply this idea to agents rather than to single outputs.
- Why an independent implementation, not just an independent instance, is what redundancy requires — the same argument that made triple-redundant flight computers use different codebases.
Key terms
TERMS #| Term | What it means |
|---|---|
| Defence in depth | stacking safeguards so that no single failure reaches the consequence; only effective when the layers fail for different reasons. |
| Invariant | a property stated so precisely that a machine can decide it, and that therefore holds by construction rather than by tendency. |
| False positive rate | how often a check refuses something legitimate; the price paid for a guarantee, and the reason narrow rules beat broad ones. |
| Chokepoint | the single place in a system through which a consequential action must pass, and therefore the only place a rule can be enforced rather than merely advised. |
Every term the collection defines is gathered in the glossary.