What it is
Evals before the system are the behavioural specification of an AI process. The eval set records what counts as working behaviour before the process has been built: 50 to 500 labelled examples of "the right answer for our process," versioned alongside the system and topped up every week from real decisions.
The principle resembles the familiar "test first, code second," but the resemblance is deceptive. In software a test is binary — it passes or it does not. An eval set aims at something harder: a distribution across three buckets. Around 60% of cases with a reference answer, 30% with an acceptable deviation, 10% edge cases and deliberate provocations.
It is used in the design phase, before the process launches, and keeps working throughout evolution. Without this practice an AI process cannot move from A2 to A3 or above on the scale of autonomy levels — a person will go on checking every decision by hand.
How to do it
1. Build the first set: 50 reference cases
In week one, the process owner and one domain expert work through 40 to 50 real decisions from the past month's history, writing the expected answer for each. Do not attempt fifty in one sitting: labellers tire and start copying. Better forty in two hours, topped up to sixty over the following fortnight.
2. Run the baseline
A baseline of 0% is normal — it is the starting point you measure growth from. In week two, an hour is enough, run by hand or through a simple script.
3. Write the runner
A runner for the eval set takes a couple of hours with an AI assistant. What matters is that it is versioned code rather than a one-off formula in a spreadsheet — otherwise the run will not survive the first iteration.
4. Iterate on context and prompt
Four to six weeks of work takes you from 0% to 70–80%. Every disagreement in production becomes a new case in the set. If 8% of real enquiries are holiday orders and the set has none, add a dozen cases and let the number catch up.
5. Name an owner of quality
Without a person whose name sits next to the eval set, within two months the team gets used to the red number and stops reacting. That is the moment the practice turns into a ritual, and it is the most common reason it fails.
When it applies
Run evals before the system on every AI process meant to go beyond A2 autonomy. Without an eval set the process stays on manual review forever.
Do not run them on two kinds of work. First, creative tasks — writing, exploratory research — where there is no single right answer; there you sample 10–20% of outputs and have an expert judge them. Second, long-horizon strategic decisions, where feedback arrives years later and the context has changed by then. Those stay at A1, because there is no feedback loop to build on.
In a small company, start in week one — while the process is simple, labelling is cheap. In enterprise, start after the process audit, because the eval set often has to be split by department and jurisdiction from the outset.
Who is accountable
Ownership of quality is either a role of its own or part of the process owner's role. Without a name next to the eval set the practice does not work.
In a large organisation this is an eval specialist, a staffed role. They work with compliance on the safety checks and with a domain expert on accuracy.
In mid-market the role usually grows out of a QA engineer, with around 30% of their time protected for it.
In a small company the function sits with the process owner: a minimum of four hours a week of protected time, plus an outside auditor for a couple of hours a month. That is the lower bound at which the practice still works. Below it the method is technically being followed and substantively is not.
Common mistakes
Quality theatre. The eval set was built once at launch; three months later the process is handling new kinds of request and the set has none of them. The number on the eval set reads 95%, real traffic sits at 70%, and the dashboard is green throughout. The tell: the set's version has not changed in two months or more. The cure: updating the set is its own line in the quality owner's weekly plan.
Evals written after production, not before. "Ship first, cover it later" turns evals into after-the-fact QA. The specification stops existing: what counts as working is defined by whatever is working right now. The cure: the discipline of the first iteration. On an empty set the result is 0%, and that is fine.
Tuning to the set. The team optimises against the eval set, the agent passes it perfectly, and production quality does not move. The eval set has gone from being a specification to being a model of reality that nobody checks against reality. The tell: the eval score rises while the business numbers stay flat or fall. The cure: two independent signals — the statistical one (evals) and the behavioural one (the business number). If they disagree two weeks running, the set is reweighted to the traffic you actually have.
