Guardrails that are enforced, and guardrails that are merely requested

The distinction that decides everything

Almost every AI system claims to have guardrails. Very few can say where they live, and that single question separates two categories of system that look identical from the outside.

• A requested guardrail is an instruction to the model. "Never recommend a position larger than 5% of the portfolio." "Do not give medical advice." "Always ask before sending an email."
• An enforced guardrail is a check outside the model that runs regardless of what the model produced. The 5% limit is evaluated against the actual number in the output, and output that exceeds it does not leave the system.

Both look like guardrails in a demo. Only one of them is a boundary.

The test is simple: if the model ignored the instruction entirely, would anything stop it? If the answer is no, you have a request.

Why requests fail in ways that are hard to see

A request usually works. That is the problem.

If your instruction is honoured 98% of the time, the system appears controlled across every test you are likely to run, and the 2% arrives later, unevenly, and often in exactly the situations the guardrail existed for. Unusual inputs are both the ones most likely to defeat an instruction and the ones where the constraint mattered most.

There are three specific ways requests degrade:

1. Instruction dilution. As the prompt grows, earlier instructions compete with later ones. The constraint written in week one is now surrounded by three hundred lines of task detail.
2. Adversarial or unusual input. Anything that reframes the task can move the model out of the regime where the instruction was salient. This does not require a malicious user; an unusual but legitimate case does it too.
3. Silent model change. A version upgrade shifts behaviour. Nothing in your codebase changed, so nothing triggers a review, and the constraint quietly becomes less reliable.

None of these produce an error. They produce plausible output that violates a rule nobody is checking.

What enforcement actually looks like

Enforcement means a deterministic check, written in code, evaluated against the structured output before delivery.

That last part matters. You cannot enforce a rule against a wall of prose. If the model returns "I'd suggest a moderately sized position, perhaps around 6-7%", there is nothing to compare against a numeric limit. Enforcement requires structured output: a schema with a position_size field holding a number.

The sequence is:

1. The model produces a structured proposal.
2. The proposal is validated against a schema. Malformed output is rejected, not repaired by guesswork.
3. Each constraint is evaluated as code against the parsed fields.
4. Output that fails is held, not silently corrected. Silent correction destroys the evidence that a violation occurred.
5. The held item routes to a human, or is dropped with a logged reason.

Step 4 is where most implementations weaken. Auto-correcting a violation feels helpful and produces a clean-looking system with no record of how often the model tried to breach a limit — which is precisely the signal you most want.

The two categories side by side

The right-hand column is not better in every respect. It is more work, it is rigid, and it cannot express nuance. Which leads to the practical question.

When a request is the correct choice

Requests are not a failure mode. They are the right tool for anything where being wrong is cheap and the rule is a matter of preference rather than limit:

• Tone and voice
• Response length and formatting
• Which of several valid framings to prefer
• Whether to lead with a summary

Use enforcement for anything you would be unwilling to explain away in a review: money, permissions, external communication, irreversible actions, regulated claims, anything touching a person's record.

A useful rule of thumb:

If a violation would require an incident report, it needs enforcement. If it would require a shrug, a request is fine.

Building the enforcement layer, in order

1. Write the constraints down as sentences before writing any code. "The system must never recommend a position exceeding X." Vagueness here becomes unenforceable code later.
2. Convert each sentence into a testable predicate. If you cannot express it as a function returning true or false against structured output, it is not yet a constraint — it is a value.
3. Force structured output. Retrofitting a schema onto a system that returns prose is the single largest piece of work in this list, which is why it is worth doing early.
4. Evaluate constraints after generation, before delivery. A check inside the reasoning step is just another instruction.
5. Decide the failure behaviour per constraint. Hold for review, drop, or escalate. "Log a warning and continue" is not a failure behaviour.
6. Log every evaluation, including passes. "The limit was checked and passed" and "the limit was never checked" produce identical output and entirely different post-mortems.
7. Unit test the constraints directly, with inputs that should fail. A guardrail nobody has ever seen trigger is a guardrail nobody knows works.

Where this sits in an architecture

In Barion Core, policy evaluation is a distinct layer that runs after options are generated and before anything is delivered. That ordering is the whole point. A constraint inside the reasoning step is a suggestion; a constraint between reasoning and delivery is enforceable.

The practical consequence is that output failing a policy is held for review rather than shipped, and the hold itself is recorded. Over time, the rate at which output gets held is one of the more useful health signals a system produces — it tells you when behaviour is drifting toward a boundary long before anything visibly breaks.

What this does not give you

Enforcement makes a system bounded. It does not make it correct.

A system with perfect guardrails can still produce output that is within every limit and wrong on the merits. Constraints answer "is this permitted?" and never "is this good?" The second question needs evaluation and outcome feedback, which is a separate discipline.

Confusing the two is how organisations end up with immaculate compliance and poor decisions. Both are needed, and the guardrail layer is the cheaper and more tractable half.