Guardrails

Guardrails are the checks that run around a model rather than inside it. They decide what context may enter, what output may leave, which tools may be called, and which actions are prohibited regardless of how confident the model is.

Why they cannot live in the model

A model's behavior is shaped by training and can be shifted by an unusual input. A guardrail is code: it either passed or it did not, and the result is inspectable after the fact. Anything that must hold every time — an approval limit, a prohibited action, a data boundary — belongs in the deterministic layer, because “the model has been trained not to” is not a control.

What they look like in practice

Input checks: is this data permitted for this task, is the requester authorized, has sensitive content been removed or tokenized before processing. Output checks: does the response match its schema, does it cite the evidence it claims, does it stay inside the permitted action set. Terminal checks: does this action exceed the delegated limit, is a required piece of evidence missing, has a stop condition fired.

What they are not

Guardrails do not make a weak system safe. They bound the failure, which is different from preventing it. A system whose model is wrong half the time and whose guardrails catch it is a system that stops half the time — correctly, and uselessly. Quality comes from the design; guardrails make its limits enforceable.