How much of this to actually do

Evaluation has a cost, and it is not small

Everything in this course is work. Roughly, at 2026 prices in time:

• A first 100-item labelled set, with a guide and a second labeller: three to six hours.
• A harness that runs, caches and diffs: one to two days for the first version.
• A calibrated judge, including the calibration set: five hours, then ten minutes a month.
• A human review programme: eighty minutes a day, indefinitely.
• Monitoring, dashboards and alerts: two to three days, then maintenance.
• Fairness slicing, red-teaming, agent environments: days each.

Do all of it for an internal tool used by five people and you have spent a fortnight measuring something that could have been replaced by asking those five people. Do none of it for a system that decides who gets a loan and you have built something nobody can defend.

The skill is proportionality, and it is a judgement about consequences, not about how interesting the model is.

Three tiers

Tier 1: low stakes, reversible, small audience. An internal summariser, a drafting helper for your own team, a prototype.

• 20 to 30 examples, labelled by one person
• deterministic checks only: parses, complete, right language, no placeholder text
• a note in the repository saying what it is for and what it does badly

Half a day. Anything more is procedure for its own sake, and the users are close enough to tell you when it breaks.

Tier 2: customer-facing, reversible. A support assistant, a search feature, a content generator with a human in the loop.

Everything in tier 1, plus:

• 100 items, two labellers, dev and test split
• a rubric and a calibrated judge, re-calibrated monthly
• the harness in CI: deterministic checks on every pull request, judge set nightly
• slice metrics with a floor, not just an average
• online proxies logged, with a weekly look
• a small review sample, random and targeted
• the incident loop

About two weeks to establish, then a few hours a week. This is where most work sits, and it is the tier this course is written for.

Tier 3: consequential or irreversible. Money moves, a medical or legal decision is influenced, content is published unreviewed, safety is at stake, or the volume is such that a 1% failure rate is thousands of people.

Everything in tier 2, plus:

• a much larger set, hundreds to thousands of items
• an adversarial suite with harmful-completion and false-refusal rates tracked together
• explicit fairness definitions, chosen and documented, with per-group floors
• continuous monitoring with alerts and an on-call owner
• sustained human review with double-labelling
• a staged rollout with a kill switch, and a written rollback threshold
• a named person accountable for the quality of the measurement itself

Months, and a permanent cost line. If that seems disproportionate, the tier assignment is the thing to argue about, not the list.

Choosing the tier honestly

Four questions settle it:

1. Who is harmed when it fails, and how badly? Not “is it embarrassing”: who, and how much.
2. Can it be undone? A wrong draft a human edits is recoverable. A sent message, a published post, an issued refund, a rejected application is not.
3. Would anyone notice? A failure that produces a complaint is self-limiting. A failure that produces a slightly wrong number in a report nobody checks can run for a year.
4. How many people, how fast? Volume converts a small rate into a large count.

The most common mistake is not under-evaluating a tier-3 system. It is running a tier-1 process on a tier-2 product because it started as a prototype and nobody re-asked the question when it went in front of customers. Re-ask it at every launch.

Where to start, if you start nowhere

In this order, and each step is useful before the next exists:

1. Twenty labelled examples in a file. One hour. It ends more arguments than anything else in the list.
2. A script that runs them and prints a pass rate. Two hours.
3. Deterministic checks. Two hours, and often the largest single quality gain in this list.
4. Read fifty failures. Ninety minutes, and it tells you what to do next.
5. Grow to a hundred, split dev and test. Then the rest of this course, in whatever order your failures demand.

The first three items are one day of work and they put you ahead of most teams shipping AI features. Not because the rest is unimportant, but because most teams have not done the first three, and are running on demos.

The thing to keep

The habit under all of it is small and portable: before believing a system works, say what would show that it does not, then go and look. Everything else in this course is machinery for doing that quickly, repeatedly, and in front of other people.