Every extraction tool will eventually produce a wrong answer that a user catches. Not might — will. The accuracy is never 100%, the documents are messier than the test set, and given enough use, the user finds an error. The question that decides whether the tool survives isn’t whether this happens. It’s what state the user is in when it does, and that state was determined by design choices made long before the error occurred.

Consider two tools that make the identical mistake — both misread a value from a document. In the first tool, that value was presented flatly, with no signal, indistinguishable from the hundred correct values around it. The user had been trusting all of them equally. When they catch this one wrong, the lesson they learn is devastating and correct: any of these values could be wrong, and I had no way to tell. The error doesn’t cost the tool one field. It costs the tool every field, because the user now has to re-verify everything, which means the tool has stopped saving them work entirely. One caught error collapses trust in the whole output.

In the second tool, the same wrong value was flagged for review — surfaced with a specific reason, “this came from a low-quality region, please verify.” When the user catches the error, the lesson is completely different: the tool told me this one was risky, and it was right to. The error confirms the tool’s judgment instead of destroying it. The user’s trust in the unflagged fields is untouched, because the tool demonstrated that when something is risky, it says so. The same mistake that killed the first tool strengthens the second.

This is why honesty about uncertainty isn’t a nicety — it’s what determines survival of the inevitable error. A tool that claims uniform confidence is making a bet that it will never be caught being wrong, and that bet always loses eventually. A tool that surfaces its uncertainty honestly is building the thing that lets it survive being wrong: a track record of correctly identifying its own risky outputs. The flagged error is a deposit in that account. The unflagged-but-wrong error is a withdrawal that can overdraw it entirely.

The implication for building runs backward from the error you can’t prevent. You can’t get to 100% accuracy, so design for the moment you’re caught at less than 100%. Make sure that when the error surfaces, it surfaces in a field you’d already flagged — which means investing in the honest risk signals, the citations, the absent-vs-unknown distinctions, the calibrated review prompts, all the machinery that earns the user’s differentiated trust. None of that improves your accuracy. All of it determines whether your accuracy being imperfect is a survivable fact or a fatal one. The first wrong answer is coming. Everything you build before it decides what it costs you.