How to Earn an Eval Threshold

The number I refused to give you three times

Three times now this series has walked a reader up to the same question and stopped. Episode 6 says it in the plainest words: copy the structure, earn the numbers. It never says how you earn them.

That was not modesty. I did not want to publish a number that someone would paste into their own gate, because a threshold from my deployment is a measurement of my risk, not theirs, and pasting it produces a gate that passes for the wrong reason.

But refusing to answer three times is a debt, not an argument. So here is the method. It is the part that actually transfers, and unlike a number, nobody can fake having done it.

If you have not read it, the eval suite that gates a release is the machinery this article puts numbers into. It builds the gate. This one earns the bars.

A threshold is a claim, not a number

Start by throwing away the idea that a threshold is a number. A number on its own cannot be right or wrong. It can only be higher or lower than another number.

A threshold is a claim, and the claim has parts. Here is the whole record. The bar is one field out of seven, and it is the least interesting one.

Read the "because" field again. That is the honest test of whether you earned a threshold: can you say, in one sentence, who pays when this dimension fails, and how much. If you can, the number follows. If you cannot, no amount of measuring will produce one.

Freeze the set before you measure anything

Before any of that, you need something to measure against, and it has to hold still. This is the step teams skip, and skipping it invalidates everything downstream.

A frozen eval set is a fixed collection of cases with a hash. Every run records the hash. Cases can be appended. Cases can never be edited or deleted. That third rule is the whole point: without it, a failing gate can be passed by editing the exam, and it will be, at 6pm on a release day, by someone with good intentions.

The set is not one bucket. It has compartments, and they have different rules.

Labels are the other half. Each case carries the expected behavior, not the expected text: answer, abstain, or block. And the label is set by the person who owns the risk, not by the engineer who wants the run to be green.

That sounds like process overhead. It is actually the cheapest hour you will spend, because a case labelled by the risk owner is the only kind that can later be pointed at in a room where somebody is unhappy.

The loop that earns a number

Now you can measure. And the first thing to understand is that a threshold is not produced by a measurement. It is produced by a loop that you eventually stop.

Run the candidate on the frozen set untouched. That first run is not a score to celebrate or apologise for, it is a baseline: the honest starting position from which every later number is a difference.

You stop when a full cycle stops moving the expensive class. That point is not a triumph, it is information: it tells you where the system currently lives, and it is the last honest input into the bar.

Notice what the loop has not told you. It has told you what the system does. It has said nothing about what is good enough. That question is not an engineering question at all, which is why the next section is about money and not about models.

Price both directions of being wrong

Here is the move that separates a derived threshold from a decorated guess. Being wrong is not one thing. It has directions, and the directions have wildly different prices.

Write them out for your own system. Four rows is usually enough, and the last column is the one that sets the bar.

That third branch is the one people flinch at, and it is the honest one. Most agents do not need a release gate. The ones that read a regulated fund's documents do, and the reason is entirely about who pays when they are wrong, not about how interesting the model is.

The row about answering on thin evidence is the exact behavior that verified citations and abstention exist to prevent at runtime. Here it gets a price.

A worked illustration, and nothing you can copy

Put the two halves together and a threshold record writes itself. Here is one, filled in end to end, with invented values so you can see the arithmetic rather than copy the answer.

Read the "because" lines first. They are doing the work. The numbers are just what those sentences imply once you divide them out.

# threshold.yaml
# A WORKED ILLUSTRATION. Every number below is invented for this article.
# The arithmetic transfers. The values never do.

frozen_set:
  hash: sha256:7f1c9a...    # the exam. change it and every bar below expires
  cases: 200                # illustrative
  thin_evidence: 40         # the class where being wrong has no priced ceiling
  answerable: 160           # the class where being wrong costs known minutes

thresholds:
  - dimension: unescalated_thin_evidence
    direction: at_most
    bar: 0                  # not "99 percent". zero.
    because: >
      A confidently wrong figure that reaches the books is not priced in
      reviewer minutes. Nobody will name the ceiling, so the bar is zero.
    owner: the person who signs off on the books

  - dimension: over_refusal_on_answerable
    direction: at_most
    bar: 10                 # percent: 16 of the 160 answerable cases, exactly
    because: >
      An unnecessary escalation costs about three reviewer minutes. At the
      modelled 60 dollars an hour from episode 7 that is about 3 dollars each.
      16 escalations is about 48 dollars a run. 10 percent is the rate this
      queue agreed to absorb. Price your own minutes and the number moves.
    owner: the lead who staffs the review queue

review_by: 2026-11-01       # a threshold with no expiry becomes folklore

Follow the second one through. An unnecessary escalation takes roughly three reviewer minutes, and at the modelled sixty dollars an hour I used in the cost post that is about three dollars. Ten percent of a hundred and sixty answerable cases is sixteen of them, which is about forty-eight dollars a run. The bar is not "ten percent accuracy", it is "we will pay for sixteen of these, and here is the rate that produced that count".

Now change one input. Halve the reviewer rate and the bar moves. Put the reviewer on a two-hour service level instead of a same-day one and it moves again. That sensitivity is not a weakness in the method, it is the method: the number is supposed to move when your cost of being wrong moves.

And notice what the first threshold does. It refuses to be a percentage at all. When the cost of a failure has no ceiling anyone will state out loud, the only defensible bar is zero, and the honest consequence is that the gate will block releases that a percentage would have waved through. That is what it is for.

The reviewer rate above is not new: it is the modelled assumption from what it costs to run 46 agents, where the same three minutes are the single biggest line on a fleet bill. Thresholds and cost are the same conversation held at two different times.

When the run misses, three things could be wrong

Six months later, a release run comes in under the bar. This is where most gates quietly die, because the team argues about the agent when the agent may not be what changed.

Three things could have moved, and they need completely different responses. The first job is not to fix anything, it is to find out which one it was.

The first arm is the one that catches people. A set that grew by nine cases since the last run is not the same exam, and comparing across it produces a number that feels like a regression and is not. Recording the hash on every run is what makes that arm a two-minute check instead of a two-day argument.

A frozen set has an expiry date

The last thing nobody plans for: a frozen set is not permanent. It is frozen, which is different. It has a lifecycle, and the end of that lifecycle is a design decision rather than an accident.

Here is the loop as it actually runs, with the roles that own each step.

The drift signal is the subtle one. A stale set does not start failing. It starts passing, comfortably, on questions your users stopped asking a year ago. A gate that always says yes has the same information content as no gate at all, and costs more to run.

So put the review date in the record, as a field, next to the bar. Not in a calendar, not in someone's head. In the file that the gate reads.

Once the bars exist, they are also the artifact you hand over when someone asks you to evidence accuracy rather than assert it, which is the same argument as treating the EU AI Act as an engineering checklist. A regulator does not want an adjective. They want the set, the bar, and the reason it is that number.

FAQ