Evals as release gates and runtime guardrails

Why it matters

An eval set that runs when someone remembers is a dashboard. An eval set that blocks a merge is a gate. The difference is who decides whether a regression ships: the number, or a person under deadline. By 2026 the discipline has converged on three layers of the same checks run at three points: before merge, on a canary, and inline in production, with failures from the last feeding the first. Interviewers ask for the pipeline because it is where evals become engineering.

The idea

Offline gates in CI

Every pull request that touches a prompt, model, tool schema or retrieval setting runs the set; the job fails when any metric falls below its threshold. Thresholds are per metric: faithfulness at or above 0.85, schema validity at 1.0, goal accuracy at or above 0.90, forbidden actions at zero. Regression against the last release sits beside the absolute floors: a drop of more than two points on any metric or segment blocks even above the bar. Cost and latency are gates too: median tokens per case and p95 seconds per case have budgets, because a prompt that lifts quality by one point and doubles cost is a regression. Print the diff, by segment, in the pull request.

eval set v14 on PR 812  (against release 3.7)
faithfulness    0.87 -> 0.85  (-2.0)   floor 0.85      PASS at bar
goal accuracy   0.91 -> 0.93  (+2.0)                   PASS
p95 latency     4.1s -> 2.5s  (-39%)   budget 5.0s     PASS
forbidden       0    -> 0                              PASS
billing/pt      0.84 -> 0.79  (-5.0)   segment floor   FAIL

Canary with online evals

A green offline run says the change is at least as good on the cases you know about. A canary says it on real traffic: route one to five percent of requests to the new version and run online evals on a sample of both arms, the same judges and code checks as CI, asynchronously, alongside the product signals (thumbs down, retries, escalations). Promote when the canary matches or beats the control for a defined window; roll back automatically when it falls below. This catches what the set did not contain, and it is cheap because the judge runs on a sample.

Runtime guardrails

The third place is inline. The same checks run on every live output before it reaches the user, with a decision attached: pass, block or route. Code checks are free and run everywhere: schema, forbidden content, PII patterns, a forbidden tool call. Judge checks cost a model call of latency, so they run under a budget (a small fast model, a short rubric, a few hundred milliseconds) and only on surfaces where a bad output is costly: money movement, regulated customer-facing flows. When a check fails, block with a safe fallback, route to a human queue, or regenerate once. A guardrail is an eval with a latency budget and a decision.

The loop back

Every runtime block and every canary failure is a trace with a known problem, which makes it a case. Feed them into the offline set on a schedule, so the next pull request is tested against this week's failures. That loop is what makes the gate stricter over time without anyone writing cases by hand.

Alerting on drift

Online eval scores are a time series: alert when a seven-day rate drops beyond its noise band, and when the judge's agreement with a human sample drifts, because the judge moves when its model updates. A score that climbs without a change is also an alert: the judge got lenient, or the traffic mix shifted.

Who owns the threshold

A threshold is a product decision disguised as a number. The owning team sets it, writes down why, and reviews it at each release. Nobody lowers one to make a build pass; a failing gate means the change waits or the threshold is renegotiated in the open, reason recorded.

The three-layer convergence

Deterministic checks everywhere, judge suites on the set and on samples, and sampled production scoring with the same judges, all instrumented through OpenTelemetry so a CI case, a canary request and a production call emit the same trace shape and can be scored by the same code.