QA files a bug that reads: the model gave a wrong answer once. How do you triage it?
Vaultmark reads every document Hallmarsh AI's law firm clients plan to hand over in a case, and marks what has to be blacked out before it goes anywhere. Clementine Vesperholt owns its redaction quality. On a routine overnight check, Marcelline Duskfell found one document where Vaultmark missed a redaction a human reviewer had already caught by hand. She filed a bug. It read, almost word for word: the model gave a wrong answer once.
- Rerun the exact document and check the eval set before deciding what kind of miss this is.Why: closing it as noise, or treating it as proof the model broke, are both guesses until the evidence says which one is true.
- Slice the miss by document type before trusting the overall rate.Why: one miss in 3,140 audited documents looks tiny. The same miss, isolated to its real shape, sits inside a rate eighteen times higher.
- Rule out the audit tool itself before blaming the model.Why: a bug in how the shadow audit reads a human reviewer's marks would look exactly like a model miss on a dashboard.
- Flag the exact input pattern for mandatory human review today, before the fix ships.Why: that same pattern is still moving through the expedited tier's spot check right now, on other clients, while a real fix gets built.
- Add the pattern to the eval set, not just to this one document.Why: fixing this one file does nothing for the next hybrid document with a wrapped number nobody has tested.
- Say plainly whether the miss predates the last model update or not.Why: a bug filed nine days after a ship date gets blamed on the ship date by default, and here, that default is wrong.
How to answer this, stage by stage
Nobody is grading whether you know the letters T, R, A, C, E in order. They're grading whether one miss in a bug ticket makes you go find out what it actually is, instead of guessing.
Let's learn
What does it actually mean when a bug report says a model got something wrong, just once? In most software, not much. In a tool built to black out social security numbers before they reach the other side of a lawsuit, it can mean a great deal, or almost nothing. The only way to know which is to go find out.
Vaultmark reads every document a law firm plans to hand over in a case, and marks what has to be redacted before it goes anywhere: private conversations between a lawyer and a client, personal information like social security numbers and medical record numbers, and business secrets covered by a court order. Hallmarsh AI built it. About 340 law firms use it, including Quilfeather and Wexbourne LLP.
Most documents Vaultmark sees are plain: real, selectable text, no scanning involved. On those, Vaultmark misses a redactable item about once in every 2,000, checked against real human decisions for the last 14 months. Some documents are harder: a scanned timesheet pasted into a digital memo, a photographed table with a coffee ring on one corner. Vaultmark has to read these with OCR first, guess where one cell ends and the next begins, then decide what to black out. On these hybrid documents, the miss rate has always run higher, about one in 90. That gap isn't a secret. It's in the product's own numbers.
Every night, Vaultmark's shadow audit reprocesses about 1 in 20 documents that already have a completed human redaction sitting next to it, and quietly compares the two. Over the last 30 days, that covered 3,140 documents. Only one of them was a full miss, a place where the model said nothing needed redacting and a human had blacked something out by hand.
Here's the turn. On its own, one miss in 3,140 audited documents, about 0.03 percent, isn't alarming. Sliced down to just the 268 hybrid documents in that sample, it's about 0.4 percent, still below the category's usual 1.1 percent. By every rolled up number Marcelline could pull that morning, this looked like nothing worth a real investigation. The real problem was that none of those numbers were fine grained enough to say so.
What it costs at its worst: this specific miss got caught, because Quilfeather and Wexbourne pay for full human review on every page, on every matter. Around 60 of Hallmarsh AI's 340 clients don't. They use an expedited tier for high volume regulatory productions, where only 8 percent of Vaultmark's high confidence calls get a human spot check, not all of them. If this exact input shape, a wrapped number inside a scanned table cell, sits at a real miss rate far above 1.1 percent, it is quietly moving through that expedited tier right now, on other clients, with nobody checking most of it by hand.
What I would leave alone: native-text documents don't need extra scrutiny. A miss rate of 1 in 2,000, checked against 14 months of real human decisions, is already about as solid a number as this kind of system gets. Adding process there would slow down the majority of documents for no real benefit.
The lesson: a single miss inside a good process is not proof the model is broken. It's also not proof it's fine. The only honest answer sits in the gap between those two, and you don't get to skip finding it just because the bug ticket only lists one instance.
Now here is the same thing as a story
Read the short version above when you're in the room. Read this one when you want to feel why "the model gave a wrong answer once" turned into three days of work instead of one closed ticket.
Every Thursday morning, Marcelline Duskfell pulls the shadow audit's overnight results before anyone else is at their desk. Most Thursdays, the report says the same thing it always says: zero full misses, a handful of low confidence calls flagged for review, nothing that needs a ticket.
She built that habit over 14 months of the number holding steady. Vaultmark had earned it. Clementine Vesperholt, who owns its redaction quality, had stopped attending the Thursday review in person around month nine. The dashboard was reliable enough that a green report didn't need a second set of eyes.
This Thursday wasn't green. One line, in a sea of matches: a document from a production for Cransford Freight, a scanned timesheet pasted into a digital memo, row 47. Vaultmark's call: no redaction needed. The human reviewer's call, made days earlier by Endeleyo Rooksgate on the Quilfeather and Wexbourne team: a social security number, blacked out by hand.
Before she touched anything else, Marcelline checked the boring explanation first. The shadow audit reads a reviewer's redaction marks off the document's own annotation layer, and that parsing had broken once before, on a different matter, months ago. She pulled the raw annotation data for row 47. It was clean. Endeleyo really had marked that number. Vaultmark really had left it alone. The miss was real.
Marcelline's ticket read, almost word for word: the model gave a wrong answer once.
Clementine opened it Thursday afternoon and did the thing that's easy to skip: she asked what the ticket actually proved, instead of what it felt like it proved. One miss, on its own, proves almost nothing. So she ran the test that would.
She had Vaultmark reprocess the exact same document, the exact same row, twenty times. Twenty times, it missed the same number. Not eighteen out of twenty. Not a coin flip. Every single time.
That ruled out plain randomness for this input. It didn't yet say whether this was a brand new problem or an old one nobody had found. So Clementine checked Vaultmark's golden eval set, 2,400 labeled documents, for anything shaped like row 47: a number that wraps across a line inside a scanned table cell, split by the scan itself rather than by the number's own formatting. Zero examples. Not one.
The timeline made the update look guilty. Vaultmark had shipped a change to its scan preprocessing nine days before Marcelline filed the ticket, meant to read old, blurry scans faster. It would have been easy to write that down as the cause and move on. Clementine didn't. She pulled 50 archived documents from before the update shipped, ones sharing the exact same shape: a numeric token wrapped across a scan tile boundary inside a table cell. Vaultmark reprocessed all 50 under the old, pre-update code path.
Nine of the 50 came back missed. Eighteen percent.
Nine of 50, from documents that had never touched the new update, meant this wasn't a new failure at all. It had been sitting in Vaultmark, untested and unnoticed, since before the eval set was 14 months old. The category average of 1.1 percent had been quietly averaging a mostly fine pattern together with this one, far worse pattern, the whole time.
The decision that had opened this door traced back to a fifteen minute conversation in the eval set's original build out, 14 months earlier. Someone asked whether hybrid documents needed their own dedicated coverage, given how rare they were. The answer, reasonable at the time, was no: 3 percent of volume didn't justify the cost of sourcing good ground truth for a document shape nobody was really sending yet. Nobody wrote down when to come back and check that percentage again.
Run that Thursday again, with the coverage decision fixed from the start. Same document, same row 47, same nine days since the update. This time, the eval set already has 40 examples of a wrapped number inside a scanned table cell, and Vaultmark has already been retrained against them. The shadow audit still might catch a miss somewhere. But a wrapped numeric token near a scan tile boundary now gets flagged for mandatory human review the moment it's detected, regardless of confidence score, whether or not the model gets that specific case right. Marcelline still opens a ticket. It closes the same afternoon, with a known cause and a known fix, instead of three days later with a number nobody had checked yet.
What Clementine would tell herself, back in that fifteen minute meeting 14 months ago: 3 percent felt too rare to bother testing for. Nobody wrote down what to do when 3 percent became 9.
TRACE: what a single miss has to survive before it's a real pattern
Not a way to dress up "let's investigate" in five letters. TRACE is what stops a single ticket from getting closed on a guess, in either direction.
And if you want to be sure it really works, try it somewhere else
Same five letters, a wheat field instead of a courtroom, and this time the wrong answer was a shadow, not a scan.
Canopyscan is Calderleigh AgriTech's drone imaging tool, used by Redmere Growers Cooperative to fly over wheat fields every week and flag early blight before it spreads. Calpurnia Fenmarch, the cooperative's staff agronomist, walks out and confirms every flagged zone by hand, because a confirmed early catch is what a farmer needs on file to file an insurance claim before a field is lost.
One Tuesday, Canopyscan called a two acre zone clean. Calpurnia walked it anyway, out of habit, and found early blight along one edge. Same shape of ticket: the model gave a wrong answer once. Same method. Timeline: a camera firmware update, six days earlier, meant to read dawn light better. Recut: shadow-edge zones, where a tree's morning shadow crosses part of a field, miss at about 4 percent, versus 0.3 percent for open flat ground, and this zone fell in the shadow-edge slice. Assume nothing: the GPS tag on the flagged zone matched Calpurnia's own walked coordinates exactly, ruling out a location mismatch before blaming the model. Cause candidates: ordinary shadow-zone variance, a new regression from the firmware update, or a blight signature partly hidden by a shadow crossing it, a shape never in the labeled training photos. Evidence test: reflying the same zone two hours later, once the shadow had moved, caught the blight correctly, and pulling archived pre-update scans of other shadow-crossed patches found a matching 31 percent miss rate. The gap predated the update. It was never tested, not newly broken.
Same rank, different lever: the fix isn't a smarter camera or a bigger scouting team. It's the same shape of decision Clementine made: add shadow-crossed blight photos to the labeled set, and flag any zone with a shadow crossing a possible blight signature for a human walk, regardless of the model's own confidence that it's clean.
Swap the trigger and it still runs.
Speed: an interviewer caps you at 90 seconds. Skip straight to it: name what shipped nearby, slice the miss, rule out tooling, name three suspects, run the one test that separates them.
Cost: no budget this quarter to expand the eval set properly. Ship the cheap version: the mandatory review flag today, backlog the eval set fix for next sprint, and say so plainly instead of pretending the gap is already closed.
The model got better, for real: say Vaultmark's overall miss rate drops by half company wide. TRACE doesn't change. A single miss still deserves the same five checks, a better model just means the aggregate number looks great right up until a coverage gap like this one gets found the same way every time.
Where people run it wrong.
They close a single miss as noise because the aggregate rate looks fine, without ever isolating the exact input shape.
They blame whatever shipped most recently, because that's the easiest story, without checking whether older data shows the same miss.
They fix the one document and call it done, without asking whether the eval set was ever built to catch this shape of input at all.
How to use it live. Ask the coverage question before naming a cause: "has this exact shape of input actually been tested, or are we all assuming it has because the category average looks fine?" That question alone usually tells you where the real gap is.
Three things worth stating directly, since this is where the real judgment sits. The alternative Clementine's team considered, and rejected, was pulling every hybrid scanned-table document out of active production the moment the bug was filed, pending investigation. It lost, because that would have frozen roughly 60 client matters mid litigation over a single unconfirmed instance, risking real court deadlines for a cause nobody had proven yet, when a targeted mandatory review flag closed the same exposure at a fraction of the cost. The AI-specific failure worth naming is an eval-set coverage gap: a wrapped number split across a scan tile boundary is a real, recurring input shape that the golden set had exactly zero examples of, so Vaultmark was never actually tested against it, not merely wrong about it. The guardrail is the mandatory-review flag on any wrapped numeric token near a scan tile boundary, which fires on the shape of the input itself rather than on the model's confidence, plus adding the pattern to the eval set so future retrains are checked against it too. And the trade-off is real and accepted on purpose: closing this gap means temporarily raising the expedited tier's spot check rate from 8 percent to full review on hybrid documents only, which slows those specific productions down and costs more reviewer time, until the retrain proves the pattern is actually fixed.
Flashcards (tap any card to flip it)
Check yourself Score: 0 / 0
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
"How do you know this isn't just the new scan update breaking something?" Response: reprocessing 50 archived documents from before the update showed the same 18 percent miss rate on this pattern, which means it predates the update and isn't a new regression.
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.
- A live AI agent you actually shipped
- A launch decision you can defend under pressure
- An interview-ready portfolio, not more flashcards
More on What changes when the product is probabilistic
- #1 Name three product decisions that change when a feature's output is probabilistic rather than deterministic.
- #2 A traditional feature either works or has a bug. Explain why that framing breaks for an LLM feature.
- #3 What does 'correct' mean for a summarization feature? Give a definition your engineering team could test against.
- #5 Explain the difference between a defect and an acceptable error rate to a non-technical executive.
- #6 Why can you not write an acceptance criterion like 'the output must be accurate' for a generative feature?
- #7 Describe how you would set a quality bar for a feature whose output is free text.