This is one of four articles on decision-grade blueprints: pictures of AI products good enough to base decisions on, before anything is built.
Tuesday morning, just after half past eight. Victor, a recruitment consultant at a staffing agency, opens Marek's file. Welder, eight years' experience, CV in Polish, applying to a metalworking company. The system suggests inviting him for a practical test. The screen says so in a few lines. It looks like an answer.
It's actually a stack of decisions. Whoever designs that screen decides what Victor gets to see, what he has to do, what he mustn't see, and what's left of it all afterwards. Each of those decisions has consequences: for the data you need to keep, for the processes the agency needs to have, for what the law allows, and for the quality of what Victor ultimately delivers, to his client and to Marek.
In this article, I take that one screen apart: ten decisions, in four groups.
The case in this series is fictional: an illustrative design, not a validated system. The people, the company and the data don't exist.
Ten decisions, in four groups
Choose a number on the screen or in the row above. The screen zooms in on that decision.
- What the AI found
- What the human does
- What is deliberately not there
- What comes next
Decision 1 of 10 · What the AI found
The original next to the translation
- On screen
- The translation is an aid, not the truth. The original is always alongside it, one click away.
- What it asks
- The original document has to be kept and retrievable, not just the translated text.
Decision 2 of 10 · What the AI found
A source for every finding
- On screen
- “Eight years' experience” points to the sentences in the CV it rests on. Victor checks it in two seconds.
- What it asks
- The extraction has to record where in the document each finding comes from. That is very hard to add later.
Decision 3 of 10 · What the AI found
Support in words
- On screen
- Not “0.82”, but “derived” or “incomplete”, with the reason attached: “scan half legible, standard not stated”.
- What it asks
- A status per finding, with its reason, instead of one number.
Decision 4 of 10 · What the human does
An action wherever there is uncertainty
- On screen
- Not just “diploma can't be verified”, but what Victor can do: propose a practical test.
- What it asks
- A process the agency can actually carry out: who organises the test, where, with which assessor.
Decision 5 of 10 · What the human does
Who decided, next to what the AI proposed
- On screen
- The system's proposal and Victor's decision stand apart, each with a name and a timestamp.
- What it asks
- Two separate states in the data, so that a human can understand, override and stop the system.
Decision 6 of 10 · What the human does
Override with a reason, but without friction
- On screen
- A short list of reasons, or his own words.
- What it asks
- Reasons kept as data: they show where the system goes wrong. Too much friction, and everyone just approves.
Decision 7 of 10 · What is deliberately not there
What the AI didn't look at
- On screen
- “Not reviewed: CV, page 3 (scan illegible); reference letter (format not supported).”
- What it asks
- The system has to record what it couldn't read. Without it, Victor assumes everything was reviewed.
Decision 8 of 10 · What is deliberately not there
Data that is deliberately missing
- On screen
- No photo, no age, no nationality, no marital status. And the screen says so.
- What it asks
- What isn't needed for the decision stays out of the model, and ideally out of the database that feeds it.
Decision 9 of 10 · What comes next
An explanation the candidate understands
- On screen
- An email in Polish: his experience fits, his certificate wasn't legible on the scan, hence a practical test. Plus two questions.
- What it asks
- Templates per language, and the reasons behind the proposal in words a candidate can read.
Decision 10 of 10 · What comes next
The log line
- On screen
- “22/10 09:14 · proposal=practical test · decision=open”
- What it asks
- Events recorded automatically, and a retention period someone decides. Only then can the agency check who gets overridden, and in which direction.
What the AI found
1. The original next to the translation. The system translates Marek's CV, but the translation is an aid, not the truth. The original is always alongside it, one click away. That seems a detail, until a translation correctly renders “spawacz” as welder but drops the very specialisation that matters for this vacancy. What it means for the build: the original document has to be kept and retrievable, not just the translated text.
2. A source for every finding. “Eight years' experience” is a claim. On screen, it points to the sentences in the CV it rests on. Victor can check it in two seconds, and someone can later trace why the system said it. What it means for the build: the extraction has to record where in the document each finding comes from. If you don't design that in from the start, it's very hard to add later.
3. Support in words. Not “0.82”, but “derived” or “incomplete”, with the reason attached: “scan half legible, standard not stated”.
What the human does
4. An action wherever there is uncertainty. The screen doesn't just say that the diploma can't be verified, but also what Victor can do: propose a practical test. Who organises the test, where, with which assessor? And is it needed before Marek is invited, or only before he's put forward to the client? A screen that proposes an action the agency can't carry out promises something nobody delivers. That's how design reveals which processes need to exist, before a line of code is written.
5. Who decided, next to what the AI proposed. The system's proposal and Victor's decision stand apart, each with a name and a timestamp. That way it is always clear that a human decided, and on what basis. For high-risk systems, the AI Act requires that people can understand, override and stop the system; for recruitment, those obligations apply from 2 December 2027. A screen that blends proposal and decision makes that impossible.
6. Override with a reason, but without friction. If Victor doesn't follow the proposal, he picks a reason from a short list, or types his own. Those reasons are worth more than they seem: they tell you where the system goes wrong, and they are the data that makes it better. But the balance is delicate. Make overriding too cumbersome, and people stop doing it. Then everyone approves whatever the AI proposes, and you've carefully designed precisely the rubber-stamp oversight you meant to prevent.
What is deliberately not there
7. What the AI didn't look at. On the right of the screen sits a small box: “Not reviewed: CV, page 3 (scan illegible); reference letter (format not supported).” With a link to the original, and a tick box for whoever checked it themselves. The system says where its view ends. It may be the cheapest box on the whole screen, and one of the most valuable. Without it, Victor assumes everything was reviewed, and trusts the proposal more than it deserves.
8. Data that is deliberately missing. No photo, no age, no nationality, no marital status. And the screen says so: “Deliberately not used.” Showing what's absent may seem unnecessary, but it changes how people trust the system. It shows that someone thought about it. What it means for the build: what isn't needed for the decision doesn't go into the model, and ideally not into the database that feeds it either. Privacy law calls that data minimisation.
The same goes for the language of the CV. Next to a name in the candidate overview, it quietly becomes a selection criterion, and a proxy for origin. It belongs with the translation, next to the original, and in contact with the candidate, as the language of the email. If language really is a requirement, such as Dutch for safety instructions, it becomes a requirement with its own support.
What comes next
9. An explanation the candidate understands. Marek doesn't see a score. He gets an email, in Polish, saying what happens next: his experience fits, his certificate wasn't clearly legible on the scan, hence a practical test. Plus two questions, about his VCA safety certificate and his availability, which Victor adds to the email or removes with a single tick. A candidate who understands why shows up. A candidate who gets a cryptic rejection drops out, and trusts the next agency a little less. The AI Act also gives people the right to a clear and meaningful explanation of certain decisions made with a high-risk system. The law doesn't require that explanation to be in their own language. That's a matter of accessibility and trust.
10. The log line. Barely noticeable to Victor, but the foundation of everything. Right now it reads: “22/10 09:14 · proposal=practical test · decision=open”. Once he confirms, a line is added: “22/10 09:21 · decision=approved, V. Berger · reason=none.” For high-risk systems, the AI Act requires events to be recorded automatically. But the real value lies elsewhere. Only with those logs can the agency later check whether candidates with a foreign diploma get overridden more often, and in which direction. How long those logs are kept is a decision of its own.
Where those ten decisions fall
None of these ten turns up in a wireframe, and none makes it into the ambitious demo: they make the picture less spectacular.
And yet each of those decisions gets made somewhere: in the design, or in production, where it costs you an incident, a complaint or an audit.
In design, each decision is quick to make in itself. What takes time is everything that comes before: talking to the people who use the screen, unpicking the decision chain, checking what the model can really do, putting the questions to the lawyer and the data architect, and making the answers converge on one screen that holds up. That work turns a five-minute decision into a defensible one.
Every decision also has a price in the build: a field in the database, an integration, a process at the agency, a retention period. Make them before the quote and you quote more accurately. Discover them afterwards and you pay for them as extra work, or as delay.
That's what a decision-grade blueprint does: it makes those ten decisions visible while they are still cheap. It asks whoever designs the screen to be able to ask the ten questions, and to know whose door to knock on: the data architect, the lawyer, and Victor, opening his twentieth file at four in the afternoon. Not to give all the answers themselves, but to bring them together in one product, and to make it traceable who confirmed what.
Three of the ten were about uncertainty: the translation, the diploma, what the AI didn't read. Suppose the top of Marek's file had said “87%”. What would Victor have known? In the next article: why a number like that usually tells you little, and how to show uncertainty in a way that helps people make better decisions.
