It is tempting to treat verification as a classification problem. You have an input, you want a label — genuine or not — and modern models are extremely good at producing labels. Ship it.
The difficulty is that a label is not a verification. A verification is a claim you are prepared to defend, and defending it requires something a bare classifier does not produce: the basis for the answer.
What a verification has to carry
- What was checked, specifically
- What evidence supported the conclusion
- What the system was uncertain about
- When it was checked, and against what state of the world
A classifier that outputs 0.94 gives you none of that. It gives you a number whose meaning depends entirely on a threshold somebody picked, calibrated against a distribution that may no longer hold.
Why this changes the design
Once you accept that the basis matters as much as the answer, the architecture changes. You stop optimising purely for accuracy on a held-out set and start caring about whether each decision can be reconstructed later. You keep intermediate signals you would otherwise discard. You version models, because “the system said it was fine” is not much use if nobody can say which system.
This is slower to build. It is also the only version that is worth anything to the person whose money or reputation depends on the answer being right.
The honest trade-off
You give up some headline accuracy by constraining yourself this way, and you should say so. A system that is 2% less accurate but whose every decision can be examined is usually the better system for high-stakes work. Not always — but usually, and for reasons you can articulate to whoever is carrying the risk.
