How Do You Verify What AI Built — Hide the Answer, Then Count the Misses

Whether you can build it is no longer the question. Who checks whether it is right, and how — that is the question.

Build speed stopped being the problem

In adoption conversations these days, almost nobody asks whether a thing can be built. It usually can. One question remains: how do we know the result is right?

That check does not happen on its own. Plausible and correct are different things, and output with a fixed shape — a report, an analysis, a verdict — looks credible even when it is wrong.

We recently did a project that forced the issue. We moved a long-codified body of knowledge into an AI-generated interpretation, and the moment it worked we hit a wall. A hundred favorable reviews are not evidence. People remember the hits.

Here is the verification procedure we set up, written so it transfers directly to business work.

One. Choose cases whose answers are already known

Verification starts with problems you already have the answer to.

In a company that means past decisions: applications approved or rejected last year, quotes whose outcome is settled, orders that ended in a claim. Start where enough resolved cases exist.

Which also means the reverse: work for which no answer key can be assembled is not ready yet. Outcomes that arrive years later, judgments that reasonable people split on.

Two. Hide the answer

This is the step most teams skip.

If you hand the AI a case along with clues that point to the conclusion, a correct result teaches you nothing. You cannot tell whether it judged or simply copied what it already knew.

So we removed everything that could lead to the conclusion. Nothing was left that identified the subject, the period, or the place. Then we verified the removal mechanically — every piece of text going into the model was scanned for identifying terms, with instructions to halt if a single one appeared.

Without that check, "blind" is only a claim. The same applies in practice: it is remarkably common to clear the outcome column of past records while leaving notes that give the outcome away.

Three. Write the criteria down first

Criteria invented after seeing the output will make anything look like a hit.

Decide in writing what counts as a match and what counts as a miss before the first case runs. We added one more rule: every passage judged correct had to carry the record that supports it. No supporting record, no score.

That single rule changes the character of the exercise. It stops being an impression and becomes something you can count.

Reading the results — how you count is half the work

Interpretation is harder than procedure. Four suggestions.

One, count hits and misses together. In our case the two reports matched the documented record in 22 and 31 places, and missed in 3 and 6. A report carrying only the first number is promotional material, not a verification result. The question to ask when someone reports AI results internally is exactly this: how many were wrong?

Two, sort the misses. They are not the same failure.

• Flatly wrong — the opposite answer. This shows the tool's limits directly.
• Half right — the direction holds but the conclusion does not. Usually the evidence was found and the final judgment slipped, which is precisely where one human step belongs.
• Does not apply — a reasonable answer to a different situation.

Three, look hardest at the third kind. That is where the defaults the tool assumes become visible. In our case the model, knowing nothing about the subject, answered as though a specific national system applied. That was not a random slip but a learned default — and the same default sits inside the answers it got right. The wrong answer simply made it visible.

Translated to business: is it answering from industry convention rather than your company's rules? From the version of the standard before the last revision? The miss list is where you find out.

Four, sort the hits as well. Statements true of anyone and statements true only of this case are different things. "Careful, but occasionally rushes" is always true. Credit belongs only to answers that could have been wrong and were not.

What verification tells you for free

The project returned something we had not planned for. Running the verification exposed several defects in the existing system.

The reason is simple: handing a human judgment to a machine forces you to write out every exception and boundary case people had been resolving silently. Errors already present come up with them.

Boundaries especially. A line a person would wave past becomes, once expressed as a calculation, the line that decides the outcome. In our case one input being slightly off flipped an entire axis of the result. Nobody knew that before the verification.

The first return on an AI project is often not a new automation but a defect found in the old process.

Retrodiction is not prediction

The most important distinction, last.

Passing on past cases means the tool is usable on work that resembles those cases. It does not mean it predicts. We set one line in bold inside the report itself: this is retrodiction, not prediction.

Include that line when you circulate verification results internally. Without it, a good result becomes grounds for overconfidence.

In short

Pick cases with known answers, hide the answers, write the criteria first, and count the misses. Then read the misses by type. How far you can trust the tool is written there.

If building took half a day and verification took longer, you are not doing it badly. You are doing it properly.

The case behind this article can be checked and reproduced at Orienteller.