A picture that holds up

This is one of four articles on decision-grade blueprints: pictures of AI products good enough to base decisions on, before anything is built.

Four people around a table. The managing director says: “We want to use AI to find the right candidates faster.” Everyone nods.

The recruiter sees a tool that gives her evenings back. The IT lead sees a model that reads CVs. The lawyer sees a file she would rather not open. The director sees a line in the annual report. Four people, four products, one sentence.

Almost every AI project I've seen take off in recent years starts like this. What's missing is a shared picture of what's actually being built. The word “AI” acts as a mirror: everyone sees their own expectations in it, until the first delivery shatters it.

Replace that mirror with a picture, one that holds up, and the four products become one.

Three kinds of pictures

There are roughly three ways to show a product before it exists.

The wireframe. Grey boxes, lines, placeholders. It's honest, because it promises nothing. But it relies on imagination, and everyone fills in the gaps differently. An approved wireframe often means twelve different products: one for each person at the table, and a few more for anyone who joined later.

The ambitious demo. It has become spectacularly cheap. With the right tools, one afternoon gets you a clickable screen that looks like a finished product: “AI match 94%”, a switch that sends rejections automatically, a dashboard that glows. Sometimes the demo is finished before anyone has discussed what it's meant to show. It's convincing, and that's exactly the problem: it shows what someone would like, not what the data, the model and the law allow.

At the bottom of that demo sits Marek. Welder, eight years' experience, CV in Polish. 61 percent, automatically rejected. Nobody at the table has ever seen him, and thanks to the demo, nobody will.

The accurate picture. It looks just as finished as the demo, but it's built on what is actually possible. It shows what the system relies on, where that support wears thin, and why. It shows where a human has to confirm.

The case in this series is fictional: an illustrative design, not a validated system. The people, the company and the data don't exist.

Wireframe — Figure 1 · The same candidate overview in three versions.

Ambitious demo — Figure 1 · The same candidate overview in three versions.

What accurate means

Accurate is not a synonym for detailed. A picture is accurate when every claim on it holds up. In practice, that means six things.

It can be built. Every number, status and suggestion comes from data that exists, or realistically could, and from a model that can handle it.
It is honest about uncertainty. Where the system is on shaky ground, it says so, in words a user understands, with the reason attached.
It shows the human. Who confirms, who may override, what gets kept. A recruitment product without a visible human is rarely one you should want.
It works in practice. Every human action the system assumes has an owner and a process in the organisation. A screen that proposes a practical test nobody can organise is not accurate, however good it looks.
It respects the rules. The law helps decide what may appear on a screen, and what must not.
It says what it isn't. What comes later is labelled “later”. What is illustrative is called illustrative.

Beneath every screen lies a second layer: which data, from which source, what the model delivers and what the human does. That layer turns a picture into a plan you can build from.

Overview — Figure 2 · The overview, and what lies beneath it: data, model, rules and the human.

Under the bonnet — Figure 2 · The overview, and what lies beneath it: data, model, rules and the human.

Why it is a craft

Behind a single calm notice such as “scan half legible, standard not stated” lie a hundred small judgements. Can this model reliably recognise a job title in Polish? May this piece of data be shown here at all? Which status will a recruitment consultant misread at four in the afternoon? What happens when two sources contradict each other? Who is liable if the system says “all clear” and it isn't? And what happens to everything that is not on the screen?

The last question deserves the most attention: an error on screen gets corrected, but data that never reaches the screen goes unnoticed.

Each of those questions belongs to a different field: data architecture, law, the psychology of interpretation, process design, visual clarity. An accurate picture is where they have to meet, on one screen, in one decision. That's why it isn't marketing. It's a technical discipline. And on top of that, the result still has to look good.

Each of them, the client included, can confirm or adjust their part on the record: the lawyer the data that is shown, the developer the source behind it, the client their expectation. Nobody is signing off on a guarantee, only on plausibility, and every sign-off has a name on it. Anything that still surprises you later stands out, because there's a shared reference point.

All lenses — Figure 3 · One screen, five lenses: each discipline asks its own question of the same picture.

ML engineer — Figure 3 · One screen, five lenses: each discipline asks its own question of the same picture.

A picture that dares to say no

In the example running through this series, the client also wants to predict candidates' “work attitude” from their CV. Whether you draw it as a percentage or as stars for commitment, it falls apart: no data carries it. A CV describes what someone did, not how they work; a model like that would mostly end up measuring writing style. How do you explain to a candidate that he scored low on “attitude”? And how do you defend that to a regulator, in a domain the AI Act classifies as high-risk?

The screen stays empty, and that is the result. Getting to that emptiness meant knowing what data exists, what the model can do, what the law requires and what the client actually wants to know. That's days of work. In other projects, I've seen the same discovery made only after months of building. By then it costs not days, but budget, trust and sometimes the project itself.

Part 1 · the screen that won't be built — Figure 4 · The screen that won't be built, with the reasons.

And a picture that sees opportunities

Reduce AI design to risk management and you miss half of it. Privacy, discrimination and liability are legitimate concerns, but they don't tell you what AI can do that a conventional system can't.

Back to Marek. A keyword filter doesn't find “welder” in his CV, because it says “spawacz”. His diploma doesn't line up neatly with a Belgian one. He drops out before anyone has seen him. A well-designed system recognises his experience, says honestly that the diploma can't be compared automatically, and proposes a practical test instead of a rejection.

That's a design choice. For Marek, it may mean a job. For a metalworking company that hasn't found a welder in months, it may finally mean that welder.

Part 1 · the candidate the filter misses — Figure 5 · The same three applications, through a keyword filter and through the accurate version.

Why it is rarely the starting point

In most projects, a picture like this doesn't come first. It comes afterwards, when the product is half built and someone asks whether the screen could “just be made to look nice”. Up front, it seems like wasted time: no code is being written yet, the demo already showed what it would look like, and the budget is earmarked for the build.

But the picture decides more than it seems to. How many rows does the table on the recruiter's screen hold? What stays visible in the side panel, and what only appears when you scroll? Find that out after the build, and you're not reworking a drawing but a product. And with a product that helps decide about people, there is more: the most expensive choices lie in what is not on the screen. Which data it uses, who confirms, what it refuses to do. Those choices get made either way. The only question is when.

A fairer objection, and one I hear often: too pixel-perfect, too much time spent on it. It has a point: show people something that looks finished, and they assume it's nearly built.

The answer isn't less polish, but exactly as much as the decision requires, with honest labels. For an architecture decision, boxes and arrows are sometimes enough. If you want to know whether a consultant approves a suggestion too quickly, you need a screen that feels like the real product.

That's why an accurate picture states, for each phase, whether it's in the quote or not. What is illustrative carries that word. And every delivery comes with a list of what I noticed outside the brief.

A client who can feel how a product works also spots the friction sooner.

Nor is a blueprint a waterfall specification. It pins down what can be decided early, turns the rest into open questions with an owner, and evolves with what the build teaches you.

Previsualisation for AI products

Film has a discipline called previsualisation. Before an expensive day of shooting, a complex scene is first mocked up on screen: camera positions, timing, what is in the frame. Nobody mistakes previs for the film. But nobody shoots a scene like that without it.

AI products deserve the same discipline. For now, I call it a decision-grade blueprint: a picture good enough to base a decision on, and honest enough to build a quote on. It doesn't replace the engineers, the lawyer or the architect. It gives them one product to agree on, before their separate choices add up to an unintended one.

In the next article, I open Marek's file and take one screen apart: ten decisions you don't see by just looking at it, but that make or break the product.

Three kinds of pictures

What accurate means

Why it is a craft

One screen, five lenses

A picture that dares to say no

And a picture that sees opportunities

Why it is rarely the starting point

Previsualisation for AI products

Written by