Your demo was honest. Production will still break it.

Your prototype reads invoices. You have tried it on maybe thirty documents and it worked on all of them. Somebody asks when it can go live and you say six weeks, because the hard part is evidently done.

The prototype is real and the thirty results were real. The inference from them is the problem, and it is a specific, well-understood one: you tested on documents you selected, and selection is not sampling.

"It works on everything I've tried" is a statement about what you tried. It is not evidence about what production will send, and the two differ in a predictable direction.

How the thirty were chosen

Nobody picked easy documents on purpose. The mechanism is subtler and it operates on everyone.

You needed documents to develop against, so you opened a folder and took some. The ones you took were the ones that opened cleanly, rendered properly, and clearly showed the fields you were extracting. A document that was a photograph of a crumpled receipt got skipped — not dismissed, just not chosen, because it was not useful for building the thing.

Then, during development, documents that failed got attention. You looked at why, adjusted the prompt, and they passed. Your thirty documents are now thirty documents the system has been specifically tuned against.

Both effects push the same way. The test set is easier than reality, and it has been fitted to.

What production sends instead

The long tail, and it is longer than it seems from inside the folder:

• Photographs at an angle, with a shadow and part of a desk in frame
• Second and third pages that assume you read the first
• A currency you did not plan for, and a decimal separator that means the opposite of what you assumed
• The PO number written in by hand in a field you assumed was printed
• A supplier who redesigned their template last month
• Scans of printouts of PDFs, three generations from anything digital
• A document that is the wrong document entirely, submitted by mistake

Each of those is a different failure with a different fix. In aggregate they are usually somewhere between ten and twenty-five points of accuracy, which is the gap between a demo that impresses a board and a feature that generates support tickets.

The measurement that replaces the guess

This does not need a research project. It needs one day and a query.

Sample, do not choose. Pull a hundred documents at random from real production data, stratified across the dimensions that vary — source type, supplier, page count, quality. The point of stratification is to force the ugly cells into the sample rather than leaving them to chance.

Label them from the document. For each field, the correct value — or that it is absent, or genuinely unreadable. Two hours of careful work.

Run the prototype and count. Per field, not averaged.

The number that comes back is your actual starting accuracy. It is nearly always lower than the demo, frequently by more than people expect, and it is the only honest input to a delivery date. The full method is in your golden set is your happy path.

What the number is for

Not to be discouraging. To make the remaining work legible.

A measured baseline of 78% on a hundred stratified documents tells you three useful things a demo cannot:

Which fields are the problem. Usually two of twelve. That is a bounded piece of work rather than an open-ended one.

Whether the target is reachable. If 15% of the sample is handwritten and the requirement is 99% on every field, the answer is no, and that conversation is much cheaper now than in month five.

What the operating model has to be. At 78%, something has to happen to the other 22%. Designing a review queue is a week; discovering you need one after launch is an incident.

Say the honest version out loud

The sentence that saves the project, delivered before anyone commits to a date:

It works on the documents we have tried. We have not yet measured it on a representative sample, so we do not know the real number. That measurement takes a day, and until we have it any date I give you is a guess.

That is not hedging. It is the difference between a plan and a hope, and it costs one day against the alternative, which is finding out from a customer.

The version of this failure we see most often is not a bad model or bad engineering. It is a good prototype, an honest demo, and a date derived from thirty documents that nobody chose at random.

More in when extraction accuracy collapses, how to break an AI demo in ten minutes, and the AI reliability audit.