Guardrails

What happens once a detector has found something. Rules are CEL over the annotations, and three axes decide how a rule behaves. The three get conflated because they all sound like “how strict is this”, but they answer different questions.

The three sit on the pipeline described in The guardrail pipeline. This page is the fork.

Which side is inspected

Requests are inspected by default. Responses are not. Scanning what the model sends back is opt-in, per detector, because it is a different cost and often a different policy. A streamed response is inspected against the commit horizon, so it is checked without being buffered. → Redact PII from model output

When the detector runs

The schedule is a latency decision, not a policy one. sync makes the request wait, overlap runs the detector alongside the upstream call, and async enforces from the next turn, so a transformer can sit on the path without the request paying its milliseconds. → Run a slow detector off the request path

Schedules says what each one concedes in exchange, and the concessions are not the same shape as each other.

Whether it enforces at all

mode: shadow annotates and records what would have happened, and denies nothing. A new detector is promoted on the evidence it recorded in shadow mode. → Run a detector in shadow mode

Mode and schedule are independent, and they are separate fields. A detector can be sync and shadow, or async and inline, and neither combination is a mistake.

Where the rules live

Guardrail rules are deployment-wide. A profile changes only which detectors run on its traffic, not what the rules say. Authorization explains what that asymmetry buys.

Where to start

A deployment under a data protection law can start from a control pack: one regime’s rules, each naming the article it serves, copied into the document with the suite that proves them. The copy is the whole mechanism; nothing reads the pack afterwards. → Start from a control pack