ConceptIntermediateEval-Driven Specification / Golden datasets and test set ownership / #23
Explain the difference between a golden set, a regression suite and a benchmark.
The direct answer
A golden set is a small stack of known-right cases you built once, by hand. A regression suite is an automatic check that nothing got worse since the last release. A benchmark is a shared, outside score that says how you compare to everyone else. All three are real tests, but none of them, by default, checks whether what you shipped is actually true, so the fix is a fourth check, aimed straight at that one question, graded against the real record instead of against another test.
Do this, in order
Write a fourth check that grades explanations against the real decision log, not against another test.Why: none of the three existing tools was ever built to ask whether a stated reason is true.
Rebuild the golden set any time the system's own logic changes, not just at launch.Why: a golden set written before a rule existed cannot test for it, no matter how well it still scores.
Read the regression suite's green pass rate as proof of format, not proof of truth.Why: it was built to check length and wording, never whether the stated reason is the real one.
Keep entering the benchmark, but stop reading it as coverage.Why: it says how you compare to other vendors, not whether one explanation is grounded in what actually happened.
Slice the real number by segment, not one blended figure.Why: the blended rate barely moved while one segment fell from 90 percent faithful to 24.
Leave the regression suite's format checks alone.Why: they still catch what they always caught, and rewriting them wastes time the real gap needs.
How to answer this, stage by stage
Seven moves. The trap in this question is answering it like a glossary entry, so the middle stages force the definitions to earn their keep against one real product.
1
Name the three tools against one real product
Say it like this
"Let me put these against something real, because the words alone don't earn much. Say a logistics company called Dockrow runs a big warehouse, and its app tells a picker which aisle to walk, plus a short line saying why. Noelle Kirkbride runs eval for that why-line. A golden set is maybe thirty-five hand-picked routes with the exact right reason written next to each one. A regression suite is five hundred real explanations pulled every week and auto-checked so nothing gets worse. A benchmark is a public score comparing Dockrow's explanations against other warehouse-AI vendors."
Why this works
Naming all three against one product turns three abstract words into three things you could point at on a screen.
2
Say exactly what question each one answers
Say it like this
"Here's the split that actually matters. The golden set answers 'do we get the known hard cases right.' The regression suite answers 'did we make anything worse since last week.' The benchmark answers 'how do we stack up against everyone else.' None of those three is the same question as 'is this explanation actually true.'"
Why this works
Naming the exact question each tool answers is what stops someone reaching for the wrong one under pressure.
3
Say what actually went wrong, in one line
Say it like this
"Noelle's team had all three green for months, and still shipped an explanation that told a picker the wrong reason for his own route, because none of the three tools had ever been asked to check if the stated reason matched the real one."
Why this works
This is the reframe. It shows you know the mix-up isn't about having too few tests, it's about which question got asked.
4
Give the fix up front
Say it like this
"So here's what I'd do. Add a fourth check: pull real explanations, look up the app's own decision log for the real, binding reason, and grade whether the two match. Not a rewrite of the other three. A new one, aimed at the one question none of them were ever asking."
Why this works
Matches the direct answer. The fix is additive, not a teardown, which reads as calmer and more credible under follow-up.
5
Walk the timeline
Say it like this
"Timeline-wise: the golden set went in at month one. The regression suite got wired into CI at month three. They started entering the benchmark at month five. Then at month six, the optimizer's own logic changed, it started holding a route back to protect a charging slot, and nobody touched the golden set or the regression suite to check whether the explanations had kept up."
Why this works
Real dates turn "nobody checked" into a fact instead of an accusation, and show the drift started at the code change, not the day someone noticed.
6
Recut by segment, then run the evidence test
Say it like this
"Split it by route type and the story changes completely. Standard routes stayed at ninety-four percent faithful. Battery-reserved routes, the new kind, fell from ninety percent faithful to twenty-four, and that slice grew from nine percent of all routes to twenty-eight over the same stretch. So I'd pull fifty of those real explanations and check each one against the decision log by hand. That's the one test that tells you which of the three would have caught this, and here the answer is none of them."
Why this works
A blended number hides a segment falling off a cliff. The by-hand check is the strongest, most concrete move in the whole answer.
7
Close on the one line, and say what stays
Say it like this
"I wouldn't touch the regression suite's format checks, and I wouldn't stop entering the benchmark, they're both still doing real jobs, just not this one. The one thing I'd take back is trusting three green tests to mean the explanation was true, when none of them had ever been asked that question."
Why this works
Closing on what stays untouched, next to the one thing that changes, shows judgment instead of blanket panic.
Let's learn
Whyline is a screen on a picker's handheld, next to the route Dockrow's warehouse app already gives. It doesn't choose the route. It just says why, something like "go by aisle 9, dock 3 is holding for a charge."
Knowledge spark: what does "faithful" mean here?
A faithful explanation states the real reason the app picked that route, the actual thing the system was reacting to. An unfaithful one sounds just as confident, but names a reason that isn't the one that actually decided anything.
When Whyline launched, Noelle Kirkbride built three checks. A golden set: thirty-five hand-picked routes with the exact right reason written next to each. A regression suite: five hundred real explanations pulled every week and auto-graded for format, right length, names an aisle, no contradictions. A spot in a public warehouse-AI benchmark, scored on how clear and useful the explanations read next to other vendors' systems. All three came back green, and stayed there. The golden set held near 97 percent. The regression suite held in the mid-90s. The benchmark score climbed from 84 to 89 over five months.
Two lines, six months: what the tests showed vs. what was actually true
What the dashboard showed: regression suite pass rate
Quiet signal: real faithfulness rate, battery-reserved routes only
m3m5m6, logic changesm9, Rowan speaks up
The regression suite's pass rate barely moved, sitting in the mid-90s for six straight months. The real faithfulness rate on battery-reserved routes fell from 90 to 24 percent over the same stretch, starting right when the optimizer's own logic changed. Nothing about that second line ever touched the first.
Here is the turn. Those three green scores were never the problem. The real story is a kind of route none of the three tests were built to check: one where the app now holds back for a charging slot, and the stated reason never caught up.
The three tests were real. All three were answering a question nobody had asked out loud: was the stated reason the true one?
At its worst, this costs the floor real minutes on a busy night. Battery-reserved routes were now more than a quarter of everything the floor walked, and three in four of those explanations named the wrong reason. Pickers who trusted the stated reason took the same wrong shortcut, over and over, night after night.
The gap between three green tests and the change none of them were built to see
The choice I would take back. Building three real tests at launch was the sensible call. Back then, the app had never given a wrong reason, so nobody thought to check for one. I would take back treating those three tests as finished once they passed, with nothing that forced a re-check the day the optimizer's own reasoning changed underneath them.
The decision that mattered
Grade every explanation that states a reason against the real decision log behind it, not against another test built for a different question. Not because the golden set, the regression suite, or the benchmark are wrong. Because none of them ever learned to ask "is this the true reason," and a test that never asks that will keep agreeing with itself, right up until a picker on the floor stops trusting the screen.
What I would leave alone. The regression suite's format checks don't need touching. They still catch a route explanation that's too long, or doesn't name an aisle, at close to the same rate they always did. Rewriting checks that already work spends time the real gap needs.
The lesson. A test can be real, and still be answering a question nobody is asking. Three green scores told us the explanations were well formed, well scored, and matched a fixed set of known cases. None of them ever asked if the stated reason was the true one.
The night Rowan Ibarra stopped trusting the reason on the screen
Read the short version above if you're short on time. This is the long version, for when you want to feel exactly where the six months went.
Noelle Kirkbride has run eval for Dockrow's warehouse software for four years. Before Whyline, her job was rating routes: was it short, was it safe, did it clear the floor fast. She built the first golden set herself, thirty-five routes nobody on the team could argue with.
For the first five months after Whyline launched, its dashboard was the easiest read in her week. Monday, she'd check the regression suite: green. She'd glance at the golden set: 97, same as always. Once a quarter she'd check the benchmark leaderboard: 84, then 86, then 89, climbing.
Early on, she also pulled twenty real explanations herself every Friday and read them the way a picker would, line by line. By month three, she was down to five. By month five, she'd stopped. The dashboards had never once told her something was wrong, so there was nothing left to check for.
Then, at a Tuesday shift huddle in month nine, a picker named Rowan Ibarra mentioned it in passing. "The app keeps telling me it's the short way," he said. "That's not why aisle 14 is slow. It's the charging queue. It's always the charging queue now." Nobody wrote it up. It wasn't a complaint. It was barely a sentence.
Noelle almost let it go. Her first thought was to add five new cases to the golden set and call it handled. But "always" stuck with her, so instead she pulled the decision log for aisle 14 and matched it against fifty real explanations from that same week.
Twelve of the fifty named the actual reason. The other thirty-eight all said some version of "shortest path," while the app itself had really held the route back to protect a charging slot.
We did not lose one wrong reason on one screen. We lost a picker's trust in every reason the app would ever give him again.
I want to say the app got worse at writing explanations. It did not get worse. It got fluent enough to sound sure of a reason it had stopped checking, and none of the three tests had ever been built to notice.
So here is the decision I would take back.
Ten months earlier, in the room where they'd greenlit Whyline, someone had asked whether the golden set and the regression suite would need touching once the optimizer's own logic changed. The room's answer was no. "The tests check the output, not the model," someone said, and it sounded right at the time, because back then the output had never lied.
I would put a fourth check in from month six, the day the charging-slot rule shipped: pull fifty real explanations, tagged by route type, and check each one against the decision log by hand. On the battery-reserved routes, that check would have caught the gap three months earlier, on the first bad batch, not the four-hundredth.
And the part I'd want to tell myself, if I could go back: we built three real tests and never once asked, out loud, which question none of them were built to answer.
What the segment split actually showed
Before blaming coverage, Noelle's team checked whether the regression suite's own scoring was even right. Two people hand-checked 20 flagged battery-reserved explanations against what the automatic suite said. They agreed on 18 of 20. The grading itself was not the problem. That left the coverage.
Share of routes versus share of wrong reasons
72%
24%
28%
76%
Standard routes No charging hold in play
Battery-reserved routes Charging slot is the real reason
Share of all routes, month nine
Share of wrong reasons found in the audit
Battery-reserved routes are 28 percent of everything Whyline explains now, up from 9 percent before the optimizer's logic changed. That same 28 percent accounts for 76 percent of every wrong reason the audit found, while none of the three tests had a check built for it.
Trusting three green tests alone
97 golden set, mid-90s regression suite, 89 benchmark, month nine
0 of the three checks ever compared a stated reason against the app's own decision log
Adding the fourth check, the week Rowan spoke up
50 real battery-reserved explanations, checked against the decision log
24 percent actually named the route's true, binding reason
Three reasons three green tests can all miss the same lie
Not because anyone cut a corner on purpose. Each of the three tools earns its own kind of trust, and that trust is exactly what lets a mistake none of them were built for slip through all three at once.
Three separate, checkable reasons the three tools get treated as interchangeable
Reason 1
The regression suite feels tested because it runs in CI, every single day.
It fires on every release, automatically, with no one asking it to. That makes it feel like the thing standing watch over quality, when all it was ever built to check is length, wording, and whether an aisle got named.
How you'd check it: list what the suite's own rules actually score, and ask whether "is this reason true" is one of them. If it isn't, the suite was never watching for it.
Reason 2
The benchmark feels authoritative because it's the industry standard.
A public score, compared against other vendors, carries weight in a way an internal number doesn't. But the benchmark grades how clear and useful an explanation reads, not whether the reason inside it is real.
How you'd check it: ask what the benchmark's own scoring criteria are. If "grounded in the real decision" isn't one of them, a fluent, confident, made-up reason scores exactly as well as a true one.
Reason 3
The golden set feels redundant once the other two exist.
Thirty-five cases, hand-built once, can start to feel like old news next to a suite that runs daily and a benchmark that runs company-wide. But the golden set was never rebuilt after the optimizer's own logic changed, so it has no case at all for a battery-reserved route.
How you'd check it: ask when each case in the golden set was last touched. If none of them post-date the last real change to the system, the set is testing an app that no longer exists.
Running TRACE on an explanation nobody fact-checked
This reads like a question about definitions, but the real job is diagnosis: work out why three real, passing tests all missed the same kind of lie. GUARD would fit if the harm landed unevenly across a protected group; here the harm is a whole kind of mistake none of the three tools ever learned existed.
T, timeline. The golden set went in at month one, built from the routes the team knew mattered most at launch. The regression suite came online at month three. The benchmark entry started at month five. The optimizer's own logic changed at month six, holding routes back to protect a charging slot. Nobody touched any of the three tests at month six, or in the three months after. The real faithfulness rate on battery-reserved routes started falling that same month, from 90 to 61 percent, while the regression suite's pass rate stayed flat in the mid-90s.
R, recut. Split by route type. Standard routes, 72 percent of volume post-change: stay near 94 percent faithful. Battery-reserved routes, 28 percent of volume, up from 9 before the change: account for 76 percent of every wrong reason the audit found. A number that looked mostly fine hid a slice that was wrong three times out of four.
A, assume nothing. Before blaming coverage, two people hand-checked 20 flagged battery-reserved explanations against what the regression suite's own rules said. They agreed on 18 of 20. The scoring was fine. The gap was real, not a grading bug.
C, cause candidates. Three, named and separate: the regression suite feels like a quality check because it runs in CI every day, though it only ever scored format; the benchmark feels authoritative because it's a shared industry standard, though it never scored whether a reason was true; and the golden set feels redundant once the other two exist, so nobody rebuilt it the day the underlying system's own logic changed.
E, evidence test. Pull 50 real battery-reserved explanations sent after the logic change, and check each stated reason against the app's own decision log. Format-style pass rate on those same 50: 96 percent. Real match to the true reason: 24 percent. None of the three existing tests was built to see that gap.
Why the evidence test is the hard step
Anyone can suspect three tests have fallen behind a real system change. The evidence test earns its place by turning that suspicion into a number: how a fresh, real sample compares against the actual record behind it. Do that comparison and you've checked something real. Call three tests "probably outdated" without it, and you've only said the same worry in a more confident voice.
Same shape, a permit reason nobody had double-checked either
A city permits office runs an AI tool that drafts the first reason a building application gets flagged as incomplete, for a clerk to review before it's sent. Elsbeth Rourke, the product lead, built a golden set and a regression suite eight months before the office added a new zoning rule for backyard units, plus a spot in a public civic-tech benchmark.
T. All three stayed green across three releases, including the month the zoning rule shipped. Applicant complaints about a flagged reason that didn't match the actual case file held steady around one in twenty for months, then started climbing five weeks after the rule went live. R. Split by whether the flag touches the new zoning rule. Non-zoning flags, 74 percent of volume: complaint rate barely moved. Zoning-linked flags, 26 percent of volume, up from 5 percent before the rule: 51 percent of them named a reason the case file didn't actually support, up from 4 percent. A. Before blaming coverage, staff hand-check 15 flagged applications against the regression suite's own verdict. They agree on 14 of 15. The scoring checks out. C. Three candidates: the regression suite feels like a quality gate because it fires on every release, though it only ever checked format and tone; the benchmark feels authoritative as a shared civic-tech standard, though it never checked whether a flagged reason matched the file; and the golden set felt redundant once the other two existed, so nobody added a single zoning-rule case to it. E. Pull 40 real zoning-linked flags sent after the rule change, and check each against the actual case file. Suite pass rate: 93 percent. Real match to the file: 46 percent.
Swap the trigger and it still runs
Speed: instead of a logic change rolled out quietly over weeks, the trigger is a same-week overnight deploy of the new charging rule. TRACE still starts with what each test was ever built to check, not with how fast the change shipped.
Cost: the team shrinks the golden set from 35 cases to 15 to save review time, on the idea the extras rarely got touched anyway. The recut still has to show which kind of route dropped out, not just how many cases remain.
The optimizer really did get better: the case on this page. Dockrow's routing genuinely got smarter about protecting the charging queue. Whyline's explanation model just never learned to say so, and kept repeating its old, simpler reasons.
Where people run it wrong
Treating three green scores as proof of coverage, instead of asking which question each one was ever built to answer.
Reading a flat regression pass rate as "nothing changed," when a fixed check can stay flat for months while the thing it never tests quietly falls apart underneath it.
Building the golden set once at launch and never rebuilding it the day the underlying system's own logic changes.
How to use it live
Buy yourself ten seconds by naming the split out loud. "So there's what these three tests were built to check, and there's whatever the system is actually doing now, which might include a mistake none of them were ever aimed at. Let me say how I'd check whether that's happening here." That's not stalling. That's where the real diagnosis starts.
Flashcards (click a card to flip it)
This is a diagnosis question wearing a definitions question's clothes, so these eight test the TRACE moves and the real figures behind them, not just the three words.
1 · THE FRAMEWORK
Which framework fits "explain the difference between a golden set, a regression suite and a benchmark," and why?
Tap to flip
ANSWER
TRACE. It's a diagnosis wearing a definitions question's clothes: why three real, passing tests all missed the same real mistake. BOUND would fit a sizing question; this is about why three scores and reality disagree.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Noelle Kirkbride, eval lead for Whyline, the route-explanation feature inside Dockrow's warehouse app. She built the original golden set and regression suite herself.
3 · THE HABIT
What did Noelle stop doing once all three tests stayed green?
Tap to flip
ANSWER
Reading twenty real explanations by hand every Friday, the way a picker would. Down to five by month three, zero by month five.
4 · THE THREE CAUSES
Name the three named reasons the three tools get treated as interchangeable.
Tap to flip
ANSWER
The regression suite feels tested because it runs in CI every day, the benchmark feels authoritative because it's an industry standard, and the golden set feels redundant once the other two exist.
5 · THE NUMBER
The golden set held at 97 percent, but real battery-reserved explanations only matched the true decision-log reason ______ percent of the time.
Tap to flip
ANSWER
24 percent, on a fresh sample of 50 real explanations pulled after Rowan's remark. The format-style pass rate on those same 50 was 96 percent.
6 · THE CHECK
Name the one test that turned the suspicion into a number.
Tap to flip
ANSWER
Pulling 50 real battery-reserved explanations and checking each stated reason against the app's own decision log, instead of trusting any of the three existing tests.
7 · THE FIX
What does the fixed setup require that the old one didn't?
Tap to flip
ANSWER
A fourth check, aimed at faithfulness, rerun any time the optimizer's own logic changes rather than only at launch, plus a segment-level read instead of one blended number.
8 · CROSS-PRODUCT TRANSFER
Section 4 runs TRACE on a different product. Which one, and what's the number?
Tap to flip
ANSWER
A city's permit-flagging assistant. The regression suite passed 93 percent of 40 real zoning-linked flags, but only 46 percent of those matched the actual case file.
Check yourself Score: 0 / 0
Multiple choice
1. Noelle's team requires every release to keep the golden set, the regression suite, and the benchmark all passing. What's the actual problem with treating that as "covered"?
A. Three tests is too few for a route-explanation feature to be judged against.
B. None of the three checks whether a stated reason is actually true, so a real mistake can climb underneath all three passing scores with nothing watching for it.
C. The three tests should be thrown out and replaced with one single score.
D. The pass bar should be lowered until every explanation gets a manual review.
Show hint
Look at what each of the three tests actually checks, and what none of them ever asks about an explanation.
Show answer
B. Each test names a specific question, known cases, nothing got worse, how we compare, and none of those questions is "is this true." No amount of passing those three catches a confident, wrong reason.
Fill in the blank
2. Battery-reserved routes grew from ______ percent of all routes to ______ percent, in the six months after the optimizer's charging-hold logic changed.
Show hint
Look at the segment chart's note under the grouped bars.
Show answer
9 percent, 28 percent. The optimizer's own reasoning shifted structurally, and that growing slice is exactly where the wrong reasons piled up.
True or false
3. True or false: once the two-person check confirmed the regression suite's own scoring agreed with a human on 18 of 20 flagged battery-reserved lines, that proved none of the three tests had a coverage gap.
True
False
Show hint
Confirming the scoring agrees with itself only rules out one kind of problem.
Show answer
False. That check (the A step) only ruled out a broken grader. It took the segment recut and the 50-line evidence test (R and E) to show the gap was real, and none of the three tests were built to see it.
Short answer
4. Name a place in Whyline's tests where you'd leave the current checks exactly as they are, and say why.
Show hint
Think about the checks that are still catching what they were always built to catch.
Show answer
Model answer: "Leave the regression suite's format checks exactly as they are, and keep entering the benchmark. Both still do the job they were built for, length and wording, comparison to other vendors, and rewriting them spends time the real gap, the faithfulness check, actually needs."
Multiple choice
5. A teammate says the real fix is simpler: just add ten more golden set cases about charging routes. Why doesn't that fully fix it?
A. Because writing ten new cases would take too many weeks to build.
B. Because ten hand-picked cases only cover ten specific routes, while the real gap is checking whether any stated reason matches reality, at the scale and freshness a fixed golden set can't give you.
C. Because the golden set's own grading already disagreed with a human check, so more cases wouldn't help.
D. Because pickers would stop trusting Whyline entirely.
Show hint
One answer treats the count of cases as the problem. The rest of the answer says the missing question is the problem.
Show answer
B. A golden set is fixed and hand-built. It can only ever check the cases someone thought to write, never a real explanation shipped an hour ago.
Short answer, apply it yourself
6. Think of a golden set, regression suite, or benchmark you rely on somewhere in your own work, not this story. Which question does it actually answer, known cases, nothing got worse, or how you compare? And what's a real mistake it could let straight through, because that was never the question it was built to ask?
Show hint
Look for a case where what's being judged could change shape while the test kept passing it anyway.
Show answer
Model answer: "A hiring rubric that regression-tests interview scores release over release answers 'did anything get worse.' It would keep passing a consistent interviewer even after the role's real needs changed, because consistency was the question it was built to ask, not whether the skill being scored still matters." Any honest answer works if it names a real case where the thing being judged outgrew the test, and the test never grew with it.
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.