Setting eval thresholds that gate a release

Split your failures into two tiers first. Safety and policy breaches block at any rate. Everything else gates on how much the fail rate moved against the last run, not on an absolute score. A gate built the other way round blocks constantly and gets disabled.

A threshold is an agreement, not a property

A threshold (the number a run has to stay inside before a change is allowed to ship) is a decision about risk. Two companies running the same feature on the same model can reasonably agree different numbers, because the cost of a bad answer is different for each of them.

That framing matters because it puts the number where it belongs. Nobody can hand you a correct threshold from outside your business, and any vendor who does is selling you their risk appetite.

Fix what the number is measured on

Before a number is agreed, the thing it measures has to stop moving.

Weights and Biases documents an evaluation as a dataset of test examples plus one or more scoring functions, used to measure performance against repeatable test cases, compare changes over time and identify regressions (a case that passed on the previous run and fails on this one). [Weights & Biases] The gate is written against that pair, never against an ad hoc run.

Then pin the version. Braintrust tracks every change to a dataset so that experiments can pin to specific versions. [Braintrust] A number is only comparable to a number taken on the same examples, so the run record carries the dataset version, the scorer set and the model identifier, or the comparison is not made at all.

Tier one: what blocks at any rate

Not every failure belongs on a sliding scale.

Galtea recommends a tiered release gate in which blocking failures such as safety or policy violations trigger a deploy block at any rate, while regressions gate on the change in fail rate instead. [Galtea]

Getting this list agreed before any number is discussed changes the whole conversation. Once a failure is in tier one, there is no negotiation about how many are acceptable, and the argument moves to whether the check is accurate rather than whether the rate is tolerable.

Keep the list short and specific. A tier one list that covers half the rubric is a gate that blocks everything, which is the failure mode this article exists to prevent.

Tier two: gate on the move

For everything else the gate watches movement against the previous run.

Galtea's published illustration of the design is a faithfulness fail rate rising from 3 percent to 5 percent[src]. [Galtea] That is Galtea's own example of how a delta gate reads, inside Galtea's documentation. It is not a threshold we recommend and not a number we carry into anyone's plan.

What does transfer is the shape, which has three parts:

• An agreed starting rate, recorded against a specific dataset version and date.
• An agreed size of move that blocks the change.
• An agreed size of move that is reported and allowed through.

That third part is the one teams leave out, and it is the reason most gates get turned off. A check with only two states, pass and block, forces every small wobble into a fight. A check with a reported band gives the movement somewhere to go.

Where a judge sets the score, name the statistics

When a judge (a model that scores another model's output against written rules) produces the number the gate reads, the gate inherits the judge's error.

Galtea recommends measuring a judge with accuracy, precision, recall, F1, Pearson correlation, Spearman correlation and Cohen's kappa rather than one statistic, and writes that a judge with 0.9 accuracy and 0.1 Cohen's kappa[src] is essentially guessing. [Galtea]

So a gate that rests on a judge produced score names which statistics it reads, and the judge behind it carries a dated calibration record. The procedure is in EV-JUDGE, and the reporting rules are covered in calibrating a judge against human verdicts.

Put the check where changes pass

A threshold that nobody enforces is a document.

Promptfoo documents running evaluations in continuous integration to test prompt changes before they reach production and to fail the build when quality thresholds are not met. [Promptfoo] The pass rate that appears in their page sits inside an example snippet, so read it as an illustration of the mechanism rather than as guidance on a number.

Braintrust recommends running evals on every pull request to catch regressions before they reach production. [Braintrust] That cadence is the one worth copying: every change to a prompt, a retrieval configuration or a pinned model runs the gate. What a gate of that shape does to a team's week is covered in running an eval suite in CI.

Record every breach, and change numbers only by decision

When a run breaches, the block holds and the output is the failing examples, the scorer that moved, the size of the move and the dataset version. Nothing is re-scored to clear it.

A threshold changes when you decide to change it. The old number, the new number, the date and the reason go into the plan's revision history. Numbers agreed today reflect today's failure list, they go stale, and they get reviewed on the same cycle as the dataset.

What a gate cannot do

Two limits are worth stating before you build one.

A gate only sees the dataset it runs on. A regression on traffic that is not in that dataset passes without comment.

A gate also only stops changes routed through your pipeline. A provider side change arrives without a pull request, which is why reruns are triggered separately under EV-RERUN and tracked against the model change log. The rest of the limits are set out in EV-THRESH and on what we cannot do.

A passing gate tells you the run stayed inside numbers you agreed on a dataset you agreed on a given date. That is a useful thing to know. It is not a promise about the model, and we do not present it as one.