Decision-grade blueprints · Part 3 of 4
Showing uncertainty without a confidence score
When 87% says nothing
A confidence score looks precise and says little. What works instead: showing what a finding rests on, and what should happen when that ground is weak.
This is one of four articles on decision-grade blueprints: pictures of AI products good enough to base decisions on, before anything is built.
Wednesday, half past eight. Victor has thirty files to get through before noon. Suppose every file has a number at the top. Marek, the welder with the Polish CV: Match: 87%. The next candidate: 84.
What is Victor supposed to do with that? Is 87 good? Is it better than 84? Does it mean Marek turns out to be a good welder in 87 cases out of 100? Or that the model is 87 percent sure of something, and if so, of what exactly: the translation, the diploma, the experience, or all of it together?
The honest answer is usually that nobody at the table knows. Sometimes not even the people who built it. And yet the number is there, big and precise, as if it measured something.
What is behind a number like that
A “confidence score” sounds like one thing. In practice, it is at least four.
A probability from a classifier. A model that learned to choose between “suitable” and “not suitable” gives a number between 0 and 1 for each choice. That is only a probability if the model is calibrated: if, of all the cases scored 0.8, roughly 80 percent really are right. Modern neural networks are often overconfident, as Guo and colleagues showed back in 2017.
A probability per word. A language model picks each next word with a certain probability. From that, you can infer how firmly the model settled on a phrasing. But confident wording isn't the same as a true statement. A model can be very sure that “spawacz” means welder, and still be wrong about which certificate goes with it.
A self-assessment. You can also simply ask a language model how sure it is. Then you get a number the model writes, the way it writes any other word. Xiong and colleagues showed in 2024 that such self-reports are overconfident and tend to cluster between 80 and 100 percent, even when the answer is wrong.
A similarity. Many recruitment “match scores” aren't a probability but a distance: how close a CV is to a vacancy. That measures similarity, not suitability. Marek, who describes his experience in Polish and in different words, then quickly loses out to whoever copied the job ad almost word for word.
If you don't know which of the four numbers is on the screen, you can't design what the user should do with it. And that very question goes unasked in many projects, because the number was already in the demo.
Behind the scenes, a system may well calculate with calibrated probabilities. The question in this article is a different one: what do you show the person who has to decide?
Why a number alone is not enough
The problem isn't the number itself, but a number without any explanation of what it measures, how reliable it is and what you should do with it. Then three things go wrong.
A number invites ranking. See 87, 84 and 79, and you read an order. Without information about calibration and margin of error, nobody knows whether that three-point difference means anything. The screen pretends it does.
A number begs for a cut-off. Sooner or later someone asks: from what score do we take people forward? Then 80 becomes a cut-off that nobody decided on, and a candidate at 79 disappears without anyone looking.
In recruitment, that is exactly the kind of automatic exclusion you want to avoid, legally too.
A number hides where the uncertainty is. “87%” doesn't say what the model is unsure about. With Marek, the uncertainty isn't in his experience but in one half-legible certificate. A consultant who knows that calls Marek and asks. A consultant who only sees 87 can trust the number or ignore it.
And people follow a system more readily the more confident it seems. A precise number looks very confident, especially with a decimal point. The design then works against the very human oversight you set out to organise.
The case in this series is fictional: an illustrative design, not a validated system. The people, the company and the data don't exist.
What it rests on
That is why Victor's screen shows no level of certainty. Strictly speaking, a model doesn't deliver certainty, but a degree of belief. And even a good degree of belief doesn't tell Victor what to do. What the system can honestly show is what a finding rests on. That comes down to three questions, kept separate, for each finding.
| Question | Possible answers | What the system does |
|---|---|---|
| Provenance: where does it come from? | In the source or derived | Shows the source; for a derivation, such as a translation, the original too |
| Evidence: how complete is it? | Complete, incomplete or contradictory | Incomplete: leaves the finding out of the proposal and suggests an action. Contradictory: shows both sources and doesn't decide |
| Review: has a human checked it? | Not reviewed, confirmed or overridden | Records who did what, with timestamp and reason |
For Marek: his eight years' experience is in the source, and complete. His job title is derived, since it was translated, but otherwise complete. His welding certificate is in the source, since there is a scan, but the evidence is incomplete: half legible, no standard. On screen, the weakest part is summed up in a single word each time; the data model keeps every answer separately.
Unlike a number, every answer is tied to behaviour.
And you set the rules behind it together with the client: is it literally in the source, was translation needed, is the document complete, do two documents contradict each other? You can check that, so you can explain it. A model's number, usually not.
One label, four questions
A pattern I come across often: all of an AI's outcomes end up in one column with one set of labels. Suitable, Not suitable, Follow up, Info. Tidy, until you look at what happens. Marek's VCA certificate is missing, so it says “not suitable”. Not because he doesn't qualify, but because there was no better box.
Four questions are squeezed into that one column: what is it, what is the verdict, what does it rest on, and what needs to happen? A filter on “suitable” misses whoever looks suitable but still needs follow-up. A report that counts “not suitable” also counts everyone the system simply couldn't read. And anyone who wants to know where the model hesitates most finds it nowhere, because uncertainty never got a place of its own.
Pull it apart and you don't get four columns, but a calmer picture: Victor sees at a glance what is in order and what still needs work. And a decision like that has to be made early. A label is quick to draw and quick to build. Pulling the data model apart later is another story: then you also have to revisit every report, filter and agreement built on it in the meantime.
Uncertainty is inherited
An AI rarely makes one decision. It makes a series, and each step builds on the previous one: reading the CV, detecting the language, translating, recognising the parts, comparing diplomas, comparing experience, ticking off requirements, making a proposal.
Take Marek's certificate. The scan is half legible. The translation that follows can't be better than what it could read. Nor can the comparison with the required standard, however convincing it looks on its own. In many systems, something odd happens next: each step reports its own confidence, and the last step only shows its own. 0.62, then 0.91, 0.88, 0.93. On screen: “certificate: meets requirement”. The uncertainty has evaporated along the way.
So the blueprint has a rule: a conclusion is never better supported than the weakest step it rests on. And the screen shows where the weakness comes from. Not “certificate: incomplete”, but “certificate: incomplete, because the scan is only half legible”. Then Victor knows what to fix: not the diploma, but the scan.
In that chain, two steps are clearly weaker than the rest: comparing foreign diplomas, and ticking off requirements that aren't literally in the CV. That is the reality of systems like these. A blueprint should show it, because that is where a human needs to keep watching.
Marek's welding certificate, through the chain of decisions
- 01 Read attachment0.62Incompletescan half legible
- 02 Translate0.91Incompleteinherited from 01
- 03 Compare diploma0.88Incompleteinherited from 01
- 04 Tick off requirement0.93Incompleteinherited from 01
- On screenCertificate: meets requirementCertificate: incomplete, because the scan is half legibleProposal: practical test
Only the last number reaches the screen. That the scan was only half legible has evaporated along the way.The consultant sees not only that something is off, but also where: not the diploma, but the scan.
Rule in the blueprintA conclusion is never better supported than the weakest step it rests on.
People doubt too, only nobody sees it
There is an uncomfortable side to this story. We demand that an AI shows its uncertainty, and rightly so. But the consultant who reads Marek's CV today without AI doubts too. It just isn't recorded anywhere. It lives in a gut feeling, in the order the CVs came in, in the time of day. That's a score too, but one nobody can see, that varies from person to person and day to day, and that you can't trace afterwards.
Research on human judgement has shown this for decades. Professionals assessing the same files diverge more than they think. In selection, fixed scoring rules usually predict at least as well as experienced experts. And field experiments, in which researchers send the same CVs under different names, show that a name alone changes the chance of an invitation.
That's not an argument for replacing the human, but for letting human and machine cover each other's blind spots. Because the machine shows what it rests on, Victor can see and correct its errors before they end up in the result. Conversely, the machine's fixed criteria filter out part of Victor's own noise: every candidate is tested against the same requirements, whatever his name and whatever the time. That only works if those criteria are sound themselves, because a model makes mistakes too, and they repeat across thousands of candidates. That is why the screen records both: where the machine is uncertain, and where the human deviates and why. Only then can you compare fairly.
Uncertainty as an asset
Shown well, uncertainty is more than a risk to manage. It yields four things a number can't.
Opportunities that would otherwise disappear. A system that steers only on certainty sets Marek aside. A system that names its uncertainty proposes a practical test.
Processes that become visible. Every “incomplete” or “contradictory” with a suggested action is a question to the organisation. Who calls the candidate? Who assesses a foreign diploma? How quickly does that need to happen? In many companies, those processes don't exist, or only in the head of one experienced consultant.
Data that makes the system better. If uncertainty gets its own place in the data model, you can measure where it sits. Does the system hesitate more with CVs in certain languages? With certain diplomas? Then you know where the model needs to improve, and where a human needs to keep watching for good. That is also the kind of monitoring the AI Act asks of whoever deploys such a system, in recruitment from December 2027.
A threshold the agency chooses itself. One number may stay, but not on the screen: the threshold. Behind “incomplete” sits a boundary. From how much uncertainty about a scanned document or a translation does EU Connect mark a finding as incomplete, rather than as in the source? It is a trade-off between extra work and missed errors, and that trade-off belongs to the agency, not in a vendor's default setting. For a safety certificate, it is stricter than for a driving licence. That is why the administrator gets a slider per type of requirement, showing straight away how many files get a task at that setting. Every change goes into the log.
What this asks of a designer
None of these choices is a matter of taste. They require knowing which number sits under the bonnet, how the decision chain runs and where it is weak, what the law expects, and what Victor can really handle at half past eight with thirty files. And they require a picture that looks calm and self-evident, so that the uncertainty helps rather than deters.
Work like this and you always see more along the way than you were asked for: a missing process, a report that won't add up, a risk outside the assignment. The final article in this series is about what you do with that. Silence isn't an option, and neither is quietly delivering it. There is a third way: Seen, out of scope.
