Guardrails scattered across prompt instructions and ad-hoc middleware are hard to audit and easy to drift. Guardrail policies bring them into one place: a declarative policy file, versioned with your code, enforced by the harness on every run.
Highlights
- Declarative policy files. Express input checks, output checks, and tool-use constraints in a single YAML policy. Policies are diffable, reviewable, and applied per environment, so staging can be stricter — or looser — than production, deliberately.
- Enforcement at the boundary. Checks run in the harness, outside the model. A policy holds regardless of what the prompt says, and regardless of what the model was persuaded to ignore.
- Uncertainty-triggered escalation. Policies can route an action to a human when confidence signals fall below a threshold — judge-model disagreement, low self-consistency across samples, or an out-of-distribution input. The run pauses, a reviewer approves or rejects, and the decision is recorded in the trace.
- Graduated responses. Each rule declares what happens on breach: block, rewrite, retry with a constrained prompt, or escalate. Failing closed is the default.
- Full audit trail. Every policy evaluation — pass, breach, and escalation — is logged and queryable alongside the run trace.
Why it matters
The interesting failures in production are not the clearly prohibited actions but the ambiguous ones, and a system that must choose between blocking everything and allowing everything will do both badly. Escalation gives the harness a third option: ask someone. Knowing when to defer is a competence, not a limitation.