The Shape of Uncertainty

The short version

A product can express uncertainty in exactly four ways: show confidence, hedge the language, stay silent, or ask. Nothing else is available. Which one to use is decided by what a wrong answer costs the person reading it and whether they can verify it, not by how uncertain the model happens to be. Most products pick one move and apply it everywhere, which is why they read as either falsely confident or uselessly hedged. The artifact is a table with one row per surface, and the last column in it is the exact copy.

The hardest sentence to write in an AI product is the one that admits the system does not know.

Everything about the medium pushes against it. The output is fluent, the layout is confident, and the model produces the same clean paragraph whether it is certain or improvising. Uncertainty has to be put in on purpose, in words somebody wrote, or it does not appear at all.

And there are only four ways to put it in.

The four moves

Show confidence. Give the answer, attach a signal about how sure the system is.

Hedge the language. Give the answer, soften the claim inside the words themselves.

Stay silent. Show nothing rather than a weak answer.

Ask. Get the missing input from the user instead of guessing at it.

That is the complete set. Every uncertainty pattern you have seen is one of these four or a combination of them, which makes this a decision with four options instead of an open design problem.

Almost every team chooses based on how uncertain the model is. Low confidence, add a badge. That is the wrong input.

The right input

What does a wrong answer cost the person reading it, and can they check it.

Teams get the bottom row wrong most often. When the mistake is expensive and the user cannot check the work, a confidence badge does not transfer the risk to them. It adds a decoration to a decision they are not equipped to make, and then everyone involved feels covered. That is worse than saying nothing, because it manufactures the appearance of informed consent.

A close cousin of this decision is which surfaces should have a generated answer at all, and that one is When Not to Use AI.

What each move is good for

Show confidence when the user can verify the answer and the signal changes what they do with it.

Forms of it are not equal. A cited source, opened in one action, is the strongest confidence signal there is, because it lets the user do the checking rather than trusting a number. Coarse bands, high, medium, low, work when they change behavior. Numeric scores are almost always worse than bands: a number implies a calibration most systems do not have, and people read 73 percent as far more precise than it is.

The failure mode is furniture. A confidence signal shown on every output, always in the same place, becomes invisible within a week. Show it when it is low, not when it is high. If your confidence display would look identical on a great answer and a mediocre one, it is decorating rather than communicating.

Hedge when the cost of being wrong is low and the hedge changes how the sentence gets read. "Based on the last thirty days" instead of "Your usage is." "This looks like a duplicate" instead of "This is a duplicate." "I found two possible matches" instead of quietly picking one.

Universal hedging is the same as no hedging. "I might be wrong, but" attached to everything reads as an apology rather than as information, and people stop parsing it by the third occurrence. Passive constructions are worse: "it has been determined" hides who is unsure, which is the one thing the hedge was supposed to communicate.

Stay silent when a weak answer is worse than no answer. This is the most underused pattern in the set, and it is the one that separates products people trust from products people double-check.

In practice silence looks like the suggestion simply not appearing, with the manual path right there. Or a section rendering with a plain line about not having enough to go on yet, and one action that would change that. What it should not look like is a control disappearing, because a control that vanishes makes people think the product is broken. The feature stays available and returns nothing.

Silence needs a sentence. Not an apology, a next step.

Ask when one missing input is doing all the damage and the user has it.

A good ask is one question rather than a form. If you need three things, ask for the most load-bearing one and try again. It shows the work already done before asking, because a question that arrives with no account of progress reads as the system starting over. And it offers a default that is honest, "assume last quarter" rather than a pre-selection of the answer you were hoping for.

Asking as a reflex is where this goes wrong. A product that asks whenever it is uncertain has moved its uncertainty onto the user's calendar, and users notice. Ask once, remember the answer, and stop asking for that surface.

The last column is copy

This chapter's artifact is a table: one row per surface, with the cost of being wrong, whether the user can verify, the pattern, and the exact copy.

That last column matters more than it looks. Uncertainty is expressed in words almost every time, and if design does not write those words, they get written by whoever is closest to the code at eleven at night. Which is how a product ends up apologizing in one place, hedging in another, and stating a guess as fact in the third, all in the same feature.

Three things to never do, and they come up constantly.

Never express uncertainty with visual weight alone. Greyed-out text is an accessibility problem rather than a confidence signal, and a user with any contrast difficulty reads it as normal text.

Never let the uncertain state be less designed than the confident one. In a generated product the uncertain path is the common one, and it is where trust is actually built. Designing the happy path carefully and the unsure path in a hurry is designing the rare case well.

Never apologize twice. One acknowledgment, then the path forward. Repeated apology reads as a system that knows it is unreliable and has decided that is your problem, which is also roughly the truth in most products that do it. The wider version of that argument lives in Trust and Safety.

This week

Take the surface where your product is most often uncertain. Write the exact copy for all four patterns. Show confidence, hedge, silence, ask, in full sentences you would ship.

Then pick one and delete the other three.

The deletion is the design decision. Writing all four first is what makes it a decision rather than a default, and most teams have never once seen the other three written down for a surface they already shipped. This also pairs with the range spec from You Cannot Mock a Distribution, because uncertainty behavior belongs in the worst acceptable column.

The four patterns with their failure modes, the selection table, and the blank library are in The Uncertainty Pattern Library. The short version is How should a product show it is uncertain?

---

Chapter 6 of a series on the design operating model. Next: what undo means when an agent acted at 3am on the user's behalf.