A 99% approval rate is not an accuracy number

Here is a dashboard most teams would be glad to put on a slide. An AI sorts incoming paperwork, a person reviews every result, and after three months the dashboard says the reviewer approves 99% of what the AI suggests. Leadership reads that as 99% accurate. A trained person looked at every single item, so it is hard to imagine better evidence.

Then an auditor pulls 200 items at random and labels each one from scratch, never looking at the AI's answer. Seventeen are wrong. That is about 1 in 12.

Nobody lied. The 99% was a true number. It measured how often a busy person clicked approve, and nobody had asked it to measure anything else. The trouble starts when the slide says "approved" and everyone in the room hears "accurate."

I will walk through that example in whole numbers, then generalize. Approval, thumbs up and throughput are proxies. Only three independent truths tell you whether an agentic workflow is right: a blind audit, outcome truth and seeded items. The example is illustrative, not from a client.

The rubber stamp: 1,200 items, 100 wrong, 99.0% approved

Let me make the month concrete. This is the default "rubber stamp" scenario from Lab A in the course, and every number below can be rebuilt with a pencil.

The system handles 1,200 items in a month. Of those, 100 are really wrong, which is 1 in 12 (1,200 / 100 = 12). Reviewers catch 12% of the wrong items and reject none of the right ones.

The comfort comes from the 1.0%. A reviewer who overrides 1 item in 100 looks exactly like a careful person confirming a system that is right 99 times in 100. The dashboard cannot tell those stories apart, because it only sees the disagreement the reviewer chose to express.

I name the two kinds. Visible disagreement is what reviewers override. Hidden disagreement is what an independent check would override if it looked. Here the hidden part is the other 88 items, 7.4% of everything approved, carrying a green tick to whoever depends on them. The approval rate is built entirely from the visible kind.

Approval measures agreement between a system and a person watching it. Agreement is not correctness, and the person watching is not independent of what they watch.

Six proxies that look like accuracy, and three questions that expose them

A proxy is a number that is easy to collect and moves with quality on a good day, but is not quality. Proxies are not villains. Approval rate tells you something real about workload. The problem is only ever substitution: the proxy quietly takes the place of the thing you wanted.

Judge a nail factory on the number of nails and it makes millions of tiny useless ones. The nail story is a fable; the lesson is not. Whatever you count, people optimize the count. In AI systems that usually is not cheating. It is a proxy doing what proxies do.

Six proxies come up again and again in agentic workflows:

1. Approvals, where reviewers rubber-stamp a system that is usually right.
2. Thumbs up, from the few users who click anything.
3. Containment, which counts callers who gave up as resolved.
4. Judge pass rate, from a model judge nobody checked.
5. Low appeal rates, which also fall when people stop bothering to appeal.
6. Felt speed, from developers who believe they are faster than they are.

Thumbs up deserves a count of its own. Imagine an assistant that answers 10,000 questions a month. Only about 4% of users click anything, so that is 400 clicks (10,000 x 4%), and 90% of them are thumbs up. That is 360 happy clicks, and 9,600 questions that said nothing. The person holding a confident wrong answer does not know yet. The person who gave up just closed the window. Neither shows up in the 90%.

Three questions sort any metric into proxy or correctness. I ask them of every number in a design review.

A yes to any one of them means the metric needs an independent measurement standing next to it.

The lesson video tests this with three numbers frozen on screen: approval rate, thumbs up, and forms never escalated to a person. Which one could rise while quality falls? The first answer offered is thumbs up, since approval seems safer because somebody checked. The answer is all three. Rushed reviewers approve more. Confident wrong answers collect happy clicks. A form nobody escalated may simply be a wrong form nobody questioned. None of those numbers asks whether the form was right.

So keep the proxies and rename them for what they measure. Approvals measure throughput. Thumbs up measure satisfaction. Containment measures load. Each is a fine number with an honest label, and none of them is allowed to stand in for correctness.

Blind audit in counts: 17 wrong in 200, a range of 5.4% to 13.2%

Correctness gets its own measurement. The first and most direct one is a blind audit: someone labels a random sample of cases from scratch, without seeing the system's answer. Blind is the whole point. An auditor who sees the draft first is a second reviewer, subject to the same pull toward agreement.

In the rubber-stamp month, the auditor takes 200 items. Lab A uses a fixed sample so every learner gets the same answer, and you can rebuild it in a spreadsheet in a few minutes:

1. In column A, list item IDs 1 to 1,200.
2. In column B, mark an item wrong when its ID is a multiple of 12: =IF(MOD(A2,12)=0,1,0). Summing column B gives exactly 100.
3. The fixed audit sample is IDs 1 to 199 plus ID 204, which is 200 items.
4. Sum column B over those rows. The multiples of 12 from 1 to 199 are 12, 24 and so on up to 192, which is 16 items, and 204 is one more. So the audit finds 17 wrong.

The sample error rate is 17 / 200 = 8.5%. Compare that with the 1.0% visible disagreement on the dashboard. Same month, same items, same system.

If you want to try a random sample instead, add a column of random numbers, sort by it, and take the first 200 rows. Your count will land near 17 but rarely exactly on it, which is the next point.

Seventeen in 200 is a sample, and a sample comes with uncertainty. Reporting "8.5% error" as if it were the truth repeats the original mistake in a smaller font. So the audit result is a range. I use the score interval for a proportion at 95% confidence, because it behaves well with small counts and near zero, where the textbook "p plus or minus z times the standard error" version breaks. With n = 200, k = 17 and z = 1.96 (so z squared is 3.8416):

p         = 17 / 200                                   = 0.085
z^2 / n   = 3.8416 / 200                               = 0.019208
denom     = 1 + 0.019208                               = 1.019208
center    = (0.085 + 0.009604) / 1.019208              = 0.092821
spread^2  = 0.085 x 0.915 / 200 + 3.8416 / (4 x 200^2)
          = 0.000388875 + 0.00002401                   = 0.000412885
half      = 1.96 x sqrt(0.000412885) / 1.019208
          = 1.96 x 0.020320 / 1.019208                 = 0.039076
range     = 0.092821 plus or minus 0.039076            = 5.4% to 13.2% wrong
accuracy  = 1 minus each end                           = 86.8% to 94.6% right

In spreadsheet form, with n, k and z in cells, the center is (p + z^2/(2*n)) / (1 + z^2/n) and the half width is z*SQRT(p*(1-p)/n + z^2/(4*n^2)) / (1 + z^2/n). The true error rate in this month, 8.3%, sits inside the range, as it should.

Now the decision. Suppose the bar for this workflow is 98% accuracy. Gate on the lower bound, not the point estimate: the accuracy range starts at 86.8%, which is below 98%, so the result is a fail. The reason fits in one sentence: the range starts below the bar. With a bar of 85% the same audit passes, because the whole range clears it.

The lower bound also tells you how big an audit must be. To show 98% accuracy with zero errors found, you need the smallest n with n / (n + z squared) at or above 0.98: 0.98 x 3.8416 / 0.02 = 188.24, rounded up to 189. The same arithmetic gives 73 for 95% (72.99 rounded up) and 381 for 99% (380.32 rounded up). Rounding down is the classic slip: 380 clean items give a lower bound of 98.99%, a fail at 99%, while 381 give 381 / 384.8416 = 99.0%, a pass. As a sanity check, the rule of three puts zero errors in n items below about 3 / n, so zero in 300 means below about 1%. A perfect 20 out of 20 supports a lower bound of only about 84% (20 / 23.84).

One more step makes an audit honest, because auditors slip too. The lesson video tells a separate version of the story with 1,000 forms, where the auditor disagrees with the system on 14 of 200 approved forms. Someone checks those 14 against the source documents to settle who was right, a step called adjudication. Ten are real system errors and four are auditor slips, so roughly 1 approved form in 20 is wrong (10 / 200 = 5%). That is the number a release decision can rest on.

Automation bias: why reviewers catch less once the tool is usually right

Why would a careful person approve 88 wrong items? The name for it is automation bias: people tend to accept a suggestion instead of checking it. It is not laziness. When drafts are usually fine and the queue is long, clicking approve starts to look like the sensible use of review time.

The evidence is unflattering. A 2025 study ran thousands of people through tasks with AI pre-filled answers, some of them deliberately wrong. People took about the same time on wrong suggestions as on right ones. Errors that needed real knowledge of the rules were caught only about 31% of the time.

Put that catch rate into counts. Take 1,000 items where the AI gets 920 right and 80 wrong. Reviewers catch about 31% of the 80, which is 80 x 0.31 = 24.8, so about 25 get fixed. That leaves 975 approved, an approval rate of about 97.5%, and about 55 wrong items among those 975 approvals (55 / 975 = 5.6%). The rubber-stamp month, with its 12% catch rate, is the same curve pushed further.

The uncomfortable corollary is that a better review process can make the approval number worse. Lab A has a "careful reviewers" scenario to show it: the same 1,200 items and 100 wrong, but reviewers catch 80% of wrong items and also reject 1% of right ones. That gives 80 catches, 11 false rejects (1,100 x 1%, rounded), and 1,109 approvals (1,200 minus 80 minus 11), for an approval rate of 92.4%. The panel's one-line verdict: lower approval, more real checking.

The audit judges the items. It does not tell you whether reviewers are actually reading. For that you need seeded items: planted cases with known answers, slipped into the queue to see whether they get caught. In the lab, reviewers catch 12 of 20 seeded mistakes. That is 60.0%, and the score interval on 12 of 20 runs from 38.7% to 78.1%. Twenty seeds give you a wide range, but even the top of that range, 78.1%, leaves more than one planted mistake in five getting through.

The lesson video follows one team whose reviewers caught fewer than half of the seeded items. They replaced the approve button with a screen where the reviewer picks the label first and only then sees the draft. The catch rate climbed to three quarters. Approval went down, because more catches mean fewer approvals. The proxy fell while quality rose. Anyone steering by the approval dial alone would have called the best fix of the year a step backward.

One caution from the management side. Use planted cases for coaching, not for scoreboards. Turn them into a ranking and people learn to spot the plants instead of reading the items.

The same trap applies when the checker is a machine. A coding assistant builds a service, writes its own tests, and every test passes. Then an independent load test with realistic traffic the assistant never shaped shows the service reaching only a fraction of the promised load. The green tests checked what they were given. A check is evidence only with a trustworthy expected result, realistic cases, a deliberately broken version it actually rejects, and acceptance checks kept outside the builder's control. I wrote the agent side of this argument in Agents need an independent exam; this essay is the human-review half.

The dashboard to build instead

Here is what the rubber-stamp month looks like when the dashboard tells the truth. Three numbers sit side by side, each labelled for what it measures.

The third truth, outcome truth, arrives later: what actually happened in the business after the item left the workflow, such as a form that came back rejected. It is slow and often partial, but it does not depend on anyone's judgment at review time. Good designs use all three.

The module ends by revisiting the same paperwork company a year later. Approval is still on the dashboard, labelled as throughput, at 99%. Next to it sit a weekly blind audit and the seeded catch rate. The first month shows 92% audited accuracy and four in ten planted errors caught. After a better review screen and retraining, 97% and eight in ten. The approval rate never moved. Every real improvement showed up in the two numbers the old dashboard lacked.

Two rules keep this honest. The go or no-go decision sits on audited error, with a limit and an owner agreed before anyone sees results; choosing the bar afterward lets the number bend. And the gate reads the lower bound, so a lucky small sample cannot clear a bar a larger one would fail. I made the broader case for designing that gate in The release gate is the product.

Underneath both is the question I ask before trusting any number about a workflow: who produced it, and could the workflow have influenced them? Approval fails at once. The reviewer produced it, and the system shaped the reviewer by being right most of the time.

What to do Monday: a proxy inventory for one metric you own

Pick one number your team reports about an automated or AI-assisted workflow, one that someone currently reads as "how good the system is." Write a one-page proxy inventory for it, the same shape as the lab deliverable.

Write the metric, its current value and who produces it. Answer the three questions in full sentences. If any answer is yes, rename the metric for what it measures: throughput, satisfaction or load. Then name the independent measurement beside it (blind audit, outcome truth, seeded items, or a mix) and write its sample size and bar before you collect anything. Let the sizing arithmetic keep you honest: at a 98% bar, a zero-error audit needs 189 items, and a perfect 20-item spot check proves only about 84%.

Here is the inventory for the rubber-stamp month:

Metric:          Approval rate, 99.0% (1,188 of 1,200), produced by reviewers
Rise while worse? Yes. Rushed or trusting reviewers approve more.
System influence? Yes. A usually-right system trains reviewers to agree.
Worst cases out?  Yes. The 88 wrong approvals are invisible to it.
Rename:          Review throughput
Independent:     Weekly blind audit of 200 random items, adjudicated;
                 20 seeded items per month for reviewer coaching
Bar and gate:    98% accuracy, gated on the lower bound, owner named
                 before the first audit
First result:    17 wrong in 200, accuracy 86.8% to 94.6%: fail

The last line is the reason to do the exercise. A team with only the first line believes it ships at 99%. A team with the whole card knows it is somewhere between 86.8% and 94.6%, knows its reviewers catch 12% of what is wrong, and has a bar that says when to stop.

Go deeper

The lesson video "The number that looks like accuracy" (v01), from the module "The trap: proxies that look like accuracy," walks through the dashboard exercise, the adjudicated audit and the label-first review screen. It is on the engineering videos page. Lab A, the blind-audit simulator, runs the rubber-stamp and careful-reviewer scenarios and exports a result card you can check against this essay.

Go deeper: the full lesson and lab are in the Transition2 course.