ConceptAdvancedEval-Driven Specification / Writing a PRD for an AI feature / #15
How do you write requirements that survive a model version change?
The direct answer
Turn the requirement into a fixed test: a set of real, already-confirmed cases the model has to catch, scored the same way no matter which version is running underneath. Never write it as a loose capability line like "the system flags unusual entries," and never point it at a number that lives inside the model, like a confidence score, because that number means something different in every new version. Run the same test again every time the model changes, before the new version goes live, not after someone finds what it missed.
Do this, in order
Write the requirement as a fixed, scored test against real cases, not a loose sentence about capability.Why: a sentence like "the system flags unusual entries" is true of almost any model, including one that's gotten worse, so it can never actually fail.
Build the test set from real, already-confirmed cases, not invented ones.Why: a model can be tuned to handle made-up examples without getting any better at the strange, real ones that actually happen.
Set a real number the model has to hit, not just "some."Why: "flags entries" with no floor is satisfied by a model that flags one entry a year.
Never anchor the requirement to a number that lives inside the model, like a confidence score.Why: that number is calibrated differently in every model version, so the same requirement quietly means something new each time.
Re-run the test before every model version change goes live, including ones a vendor pushes without asking.Why: the drop shows up in the test weeks before it shows up in a client's real ledger.
Keep the test set current as real cases change.Why: an old test set stops checking for the thing the model actually needs to catch today.
How to answer this, stage by stage
Seven moves. Say what would make the requirement fail before you say what it says, or the rest of the answer has nothing to stand on.
1
Say why a working demo isn't a requirement
Say it like this
"Before I answer, I want to say why this question matters. A requirement that just says 'the model does the thing' can be true of a model that barely works. If I can't say what would make it fail, I haven't written a requirement yet. I've written a wish."
Why this works
Naming the trap first shows you understand why the question gets asked, not just that you know a definition.
2
Put one real product and person under it
Say it like this
"Say an accounting firm builds a tool that scans a client's ledger during an audit and flags entries worth a second look. Rasheeda Combs owns the requirements for it."
Why this works
A requirement for "an AI feature" in general is empty. It only means something once you can say whose sign-off depends on it.
3
Name the real outcome the requirement has to protect
Say it like this
"What actually matters isn't whether the model flags something. It's whether the thing a careful person would have caught during that audit still gets caught, whichever model version happens to be running that week."
Why this works
This is the L step. Skip it, and the test you write next has nothing real to aim at.
4
Turn that outcome into a frozen, scored test
Say it like this
"So I'd build a set of maybe fifty real entries from past audits that a partner already confirmed were worth flagging. Every new model version has to catch a set number of them, the same fifty, scored the same way, before it ever touches a live client file."
Why this works
This is the E step, and it's the whole answer. A requirement with no fixed test is a requirement nobody can actually check.
5
Say out loud how the loose version gets gamed
Say it like this
"If I just write 'the system flags unusual entries,' a model that flags one entry a year technically passes forever. And if I anchor it to the model's own confidence score instead, that number gets recalibrated every time the model changes, so the same requirement quietly means something different each version."
Why this works
Naming the cheat yourself tells the interviewer you understand why loose requirements fail, not just that they can.
6
Lay out what changes at each level of fragility
Say it like this
"At the loosest level, a requirement with no floor at all, I'd add a real number. One level up, a requirement anchored to the model's own confidence score, I'd move it onto real outcomes instead. One level up from that, a fixed test that only ever runs once at launch, I'd gate it to re-run on every version change. And if the test set itself goes stale, I'd refresh it with new confirmed cases without throwing out the old ones."
Why this works
This is the D step. A requirement nobody acts on differently at each level is just decoration.
7
Close on the version-change line
Say it like this
"If someone ever asks me why the tool missed something after a model update, I want to already have an answer: because it didn't pass the same test the old version had to pass. That's the whole reason to write the requirement this way before anyone needs to ask."
Why this works
This is the line worth leaving the room with. It shows the requirement was built to survive being questioned, not just to ship.
If you only get through two stages
Stages 4 and 5 are the answer. Say what the frozen test is, scored on real cases, and say how a loose version gets gamed. Everything else here is how you defend that test under follow-up.
Let's learn
Say an accounting firm builds a tool that reads a client's whole ledger during an audit and flags the entries worth a second look, the odd ones a careful person would want to check by hand.
Before the tool, a first-year associate spent about three full days combing through a mid-size client's ledger, checking anything large or out of the normal pattern. Across a busy quarter-end, that was close to 200 hours spread over the firm's audits, most of it spent confirming an entry was actually fine.
Now the tool reads a whole ledger in under two minutes. In its first year, it flagged an average of 41 entries an audit for someone to check by hand. Associates got their three days back and still caught what mattered.
Entries flagged per audit, before and after the swap
41 an audit
v2.1 through v2.8, before the swap
4 an audit
v3.0 onward, after the swap
The count dropped by nine tenths in one version change. The requirement never said what count would count as failing, so on paper, nothing here broke.
Then the model underneath the tool changed versions, the way it does every few months, on a day nobody at the firm picked. The number of flagged entries didn't drop a little. It dropped to 4 an audit.
Here's the turn. The tool didn't stop working. On paper, it still passed. The requirement only ever said the system must flag unusual entries for review, and flagging four entries is still flagging entries. Nobody had written down a number it had to hit, so there was no number for it to miss.
The new model didn't fail the requirement. The requirement was never strong enough to be failed.
The requirement passed on paper the whole time this was happening
Here's what that cost at its worst. On a client called Cobalt Ridge Manufacturing, six days before quarter-end, someone had posted a $340,000 duplicate vendor payment into a suspense account. The old version of the tool had always flagged entries like that. The new one didn't. The audit team signed off without catching it. Seven weeks later, a brand new associate doing routine manual sampling found it by hand, right as the client was using those same financials to confirm a loan agreement with their bank. The firm had to reopen the file, redo about 60 hours of work, and explain to the bank why a number they'd already relied on had moved.
Knowledge spark: what's a suspense account?
A holding spot for money nobody's explained yet. An entry sits there until someone works out where it really belongs. A normal part of bookkeeping, and exactly the kind of place a real problem likes to hide.
Once the team knew what to look for, they went back and tested the old model versions the way they should have been testing all along: against fifty real, already-confirmed entries pulled from three years of past audits.
Golden-set recall by model version
clears the 85 percent floor
falls under it, never re-tested at the time
Recall fell under the floor at the very first version after the swap. Nobody ran this test again until seven weeks later, after Cobalt Ridge.
The drop had already shown up, weeks before anyone at the firm noticed a thing. Nobody was looking, because the only thing being checked was whether the tool flagged something at all.
The choice I'd take back
We wrote the requirement as "the system must flag unusual entries for review." That's the loosest kind of sentence you can write, because almost any model, including a much worse one, can make it true forever. I'd have written a number instead: catch at least 44 of 50 real, already-confirmed cases from past audits, every single version, before it ever touches a live file.
What I'd leave alone. The part of the tool that lets an associate sort flagged entries by dollar size and export them to a spreadsheet doesn't need any of this. That's ordinary software, not a model's judgment call. It behaves the same no matter which version sits underneath it.
The lesson. If a requirement can still be true of a model that's gotten worse, it was never really a requirement. It was a description of what one model happened to do on the day someone wrote the sentence.
Now here is the same thing as a story
Use this version when you've got the time. Nobody argues with a Tuesday seven weeks after quarter-end.
The fieldwork room at Ashgrove & Kline mostly empties out by six. Around quarter-end, it stays half full past nine, coffee cups stacking up on the same three desks.
Rasheeda Combs has run the requirements for the firm's audit tools for four years. Ask her what a spec is supposed to guarantee and she'll tell you before you've finished the question. She wrote the spec for the anomaly tool herself, back when it was still a slide deck.
It went live two Januarys ago. For most of that first year, it was the best hour of anyone's morning. An associate would kick off the scan at eight, get a stack of maybe forty flagged entries back before their coffee cooled, and spend the morning working through the real ones instead of the whole ledger. Rasheeda sat in on review meetings and heard partners say the tool had given them back a week of every quarter.
The habit faded the way a good one does: quietly, and for a reason that made sense every single day. Review meetings got shorter, because there was less to review. Partners stopped asking to see the weekly flagged count, because nobody had ever been in the habit of checking it against anything. And when the count itself dropped from around forty entries to around four, nobody noticed at all, because there was nothing in the requirement telling anybody a lower number meant something was wrong.
Quietly, sometime around September, the vendor pushed a new version of the model underneath the tool. Nobody at the firm chose the date. It just changed, the way software updates now.
Then, on a Tuesday in November, the newest associate on the Cobalt Ridge Manufacturing engagement was doing the manual sample testing every audit still requires no matter what the tool says, and found a $340,000 payment sitting in a suspense account that made no sense at all. She brought it to Rasheeda with one question: "Why didn't the tool catch this? Isn't this exactly the kind of thing it's for?"
Rasheeda didn't have an answer. That was the whole problem.
We didn't lose one entry. We lost the only thing that made "the tool flags unusual entries" mean anything at all.
It would be easy to say the model got worse, and it did. But that's not really the story, because Rasheeda had no way of knowing that until she went looking. The requirement had never had a floor. It couldn't warn her, the way a broken alarm can't ring.
So here's the decision I would take back.
Years earlier, in the meeting where the requirement got written down, someone had suggested a number: the tool should catch at least as many of a set list of real past cases as the earlier version had. Rasheeda remembers thinking it sounded like more work than the launch deadline had room for. "It flags unusual entries for review" went in the doc instead. One sentence, easy to write, easy to agree on, in a room where everyone wanted to ship.
I would put the number back. Fifty real, already-confirmed entries from past audits, and a floor the model has to clear every single version, tested before it ever touches a live client file, not after a new hire finds what it missed.
Here's the replay. Same swap, same September, new spec. The version gate runs the fifty cases automatically before any new model goes near a real file. It comes back at 30 out of 50, well under the 44 the floor requires. The new version never reaches a live audit. Someone gets a message instead of a phone call: the model failed its test. Cobalt Ridge's ledger gets read by the old version for one more quarter while the vendor's new model gets looked at properly.
And the thing I'd tell myself, back in that first meeting: I wrote a sentence that sounded like a promise. It was really just a description of what one model happened to do, on one day, before anything ever had the chance to change.
LEAD, aimed at a requirement instead of a dashboard
This is a concept question about writing a PRD, but the shape underneath it is a metric question wearing different clothes: a number that has to keep meaning the same thing after something in the system changes without permission. That's LEAD, not BOUND. BOUND is for building an estimate out of parts. Here there's no estimate. There's a promise, and the whole question is whether it can actually be broken.
L, link. The real thing the requirement has to protect: whether a careful person would still catch what needed catching, whichever model version happens to be running that week. Not whether the model technically flags something.
E, early signal. A frozen test: fifty real, already-confirmed cases, and a number the model has to hit, checked the same way every single version, before it goes near a live file.
A, abuse. Write the requirement as a loose capability line, or anchor it to a number that lives inside the model, like a confidence score, and it can be satisfied by a model that's gotten worse, or it means something different every time the model changes.
D, decision. Below the floor, the new version never reaches a live file. Close to it, a person reviews everything for one more cycle while it's looked at. Clearly above it, holding for several versions running, it can carry more of the work on its own.
The check that proves a requirement is real
Try satisfying it with a model you already know is worse. If a version you'd never actually ship could still pass, the requirement was never testing anything. That's the same check run backwards.
And if you want to be sure it really works, try it somewhere else
A city permits office uses a similar tool to flag building-permit applications where the declared project value looks too low for the work described, the kind of gap that skips a required inspection. Same shape of question. "The system flags suspicious applications" survives any model version exactly the same way "flags unusual entries" did.
L. A project that actually needs an inspection gets one, whichever model version is reading the application that week.
E. A frozen set of past applications the city already confirmed were undervalued, and a floor the model has to clear on that same set, every version, before it goes live.
A. Write it as "flags undervalued applications" with no floor, and a model that flags two applications a year still passes. Anchor it to the model's own confidence number instead, and that number means something new every time the vendor updates it.
D. Below the floor, every application in that batch gets a human second look. Close to it, spot-checks continue. Clearly above it and holding, the tool can clear the routine ones on its own.
Same idea, a different desk
Swap the trigger and it still runs
It gets slower. Doesn't matter. Running fifty cases through a frozen test takes the same afternoon whether the model answers in a second or in twenty.
It gets cheaper. If the firm moves to a cheaper model to cut costs, the same test runs before that swap goes live too. Same fifty cases, same floor, no exception for a good reason.
It gets better than planned. If a new version genuinely catches more, it clears the floor with room to spare, and now there's proof of that instead of just a feeling.
Where people run it wrong
Writing the requirement once at launch and never testing it again, while the model underneath keeps changing without anyone announcing it.
Anchoring the requirement to a number the model reports about itself, like a confidence score, instead of a real, checkable outcome.
Building the test set from the easy, obvious cases because they're fast to label, so it never catches what the real, messy cases actually look like.
How to use it live
Say the version-change line first. "Before I say whether that number's good, I want to know what test it had to pass, and whether that test has ever changed." That's not stalling. That's the E step, said out loud, and it buys the time to build the real answer instead of guessing at one.
Flashcards (click a card to flip it)
1 · THE FRAMEWORK
Which framework fits this question, and what does it stand for here?
Tap to flip
ANSWER
LEAD. L is the real outcome a requirement has to protect, E is the frozen test that proves it, A is how a loose requirement gets satisfied by a worse model, D is what changes at each level of a requirement's fragility.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Rasheeda Combs, who has run the requirements for Ashgrove & Kline's audit tools for four years and wrote the anomaly detector's original spec herself.
3 · THE HABIT
What did the team stop doing because the tool kept passing?
Tap to flip
ANSWER
Checking the flagged-entry count against anything. It dropped from about forty an audit to about four, and nobody noticed, because the requirement never said what count would count as failing.
4 · THE REQUIREMENT
What's the loose sentence at the center of this story, and what should replace it?
Tap to flip
ANSWER
"The system must flag unusual entries for review" against "catch at least 44 of 50 real, confirmed cases, every model version, before it goes live." One is a wish. One is a test.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Writing the requirement as a capability line instead of a number, in the same meeting where a fixed test was actually suggested and set aside for being more work than the launch deadline had room for.
6 · THE NUMBER
The retested golden set showed recall at ______ percent on the last version before the swap and ______ percent on the first version after it.
Tap to flip
ANSWER
89 percent before. 61 percent after. That gap would have shown up weeks before anyone noticed at Cobalt Ridge, if anyone had been running the test.
7 · THE REPLAY
Same version swap, real requirement in place, what changes?
Tap to flip
ANSWER
The version gate runs the fifty cases automatically before any new model touches a live file. It scores 30 of 50, under the 44 required, and never reaches Cobalt Ridge's ledger at all.
8 · THE TRANSFER
Section four runs LEAD on a different product. Which one, and what's its early signal?
Tap to flip
ANSWER
A city permits office's tool for undervalued building applications. Its early signal is a frozen set of past confirmed undervaluations, scored the same way every model version, before the model's flag counts for anything.
Check yourself Score: 0 / 0
True or false
1. True or false: once the golden-set test passes at launch, the requirement is safe for the life of the product.
True
False
Show hint
Ask what happens the day the model underneath quietly changes.
Show answer
False. A model version can change on a day nobody at the firm picks, so the same test has to run again every time, not just once at launch.
Multiple choice
2. Which of these would count as a requirement that survives a model version change?
A. The system must flag entries the model is highly confident about.
B. The system must flag unusual entries for review.
C. The system must catch at least 44 of 50 real, already-confirmed cases, tested the same way on every version.
D. The system must match what the vendor's own benchmark reports for the model.
Show hint
Three of these point at a number inside the model, or at no number at all. Only one points at a real, fixed outcome.
Show answer
C. A confidence score is calibrated differently in every model version, a capability line with no floor is satisfied by almost anything, and a vendor's own benchmark is a fact about their tests, not about this product's real cases.
Fill in the blank
3. The retested golden set showed recall at ______ percent on the last version before the swap and ______ percent on the first version after it.
Show hint
The numbers sit right under the line chart in Section 1.
Show answer
89 percent. 61 percent. Both well clear of, and then well under, the 85 percent floor the requirement should have set.
Short answer
4. Name a place in this same tool's requirements where a loose, capability-only line is fine and doesn't need a frozen test.
Show hint
Look for a part of the tool that isn't the model making a judgment call.
Show answer
Model answer: "The part that lets an associate sort flagged entries by dollar size and export them to a spreadsheet. That's ordinary software behavior, not a model's judgment, so it behaves the same no matter which model version sits underneath it."
Short answer, apply it yourself
5. Pick a product you use yourself. Name one requirement it probably has with no fixed test behind it. What would the frozen test look like?
Show hint
Look for a claim like "accurate" or "personalized" with nothing to check it against.
Show answer
Model answer: "A music app that claims its picks are 'personalized.' The frozen test: fifty real listening histories with already-confirmed good next-song picks from actual listeners, and a floor the model has to hit on that same set, every version, before it goes live."
Multiple choice
6. If the golden set only had 10 cases instead of 50, what would most likely happen to its ability to catch a real drop in recall?
A. It would catch drops faster, because there's less to score.
B. It would get less reliable, because losing or gaining just one or two cases would swing the score a lot.
C. It would make no difference at all.
D. It would only affect speed, not accuracy.
Show hint
Think about what one wrong case does to a score out of 10, versus a score out of 50.
Show answer
B. A small test set makes every single case worth more of the score, so it swings around on noise instead of giving a steady read on real recall.
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.
