Draw the certainty boundary

Tags: forecasts, charts, uncertainty

Two numbers rendered identically make the same claim about how they are known. If one was measured and the other was inferred by a model, the interface has said something false — and it has said it in the visual channel, where a caption cannot reach.

The label is not in the channel being read

People read tables and charts by scanning shape, position and weight. Text is a different pass, made later and often not at all.

So "(est.)" beside a number is genuinely present and genuinely unread. So is a footnote, a legend entry, and a sentence under the chart title. They satisfy the author's sense of having disclosed it, which is the thing that makes them dangerous: the obligation feels discharged and nothing has been communicated.

Epistemic status has to be carried by the rendering. Not because labels are bad, but because the reader is not in the part of the interface where the label lives at the moment they form the belief.

Reserve one property, and don't spend it twice

Pick a single visual property and let it mean how well this is known, then never use it for anything else in that view.

Hatching, opacity, texture, a dashed stroke — these work because they are otherwise unemployed. Colour usually does not, because colour is already carrying category almost everywhere, and asking it to carry two orthogonal meanings produces a chart where nobody can tell whether green means revenue or means confident.

Two things fall out of choosing deliberately:

• The property should read as "less" without reading as "unimportant". Hatched is thinner than solid but not greyed out. A forecast is not a disabled state.
• It has to survive the export. A distinction that exists only in the interactive chart and is lost when someone screenshots it into a deck has failed at precisely the moment the number travels furthest from its context. That is record how it was made territory.

Draw the boundary, not just the two regions

This is the part usually missed. Styling the known region one way and the inferred region another leaves the reader to infer where one became the other, and the eye will put it in the wrong place — usually later than it belongs, because the last real value is the one that looks most authoritative.

The transition is a feature of the data and deserves a mark. A vertical rule at "today". A visible seam where the record stops. Something that answers when did you stop knowing this as a position rather than as an inference from texture.

Precision is a certainty claim

A forecast quoted to two decimal places asserts more than any model producing it can support, and it does so in a channel people read very well: significant figures.

Match precision to certainty. Round forecasts harder than actuals, and be willing to round them a lot — a projected balance of "about £2.4m" is more honest and more useful than £2,417,338.41, which invites a conversation about the 41 pence.

The fork: mark it, or don't show it

The left branch is the one worth pausing on. Marking is not always sufficient — for a number that will be acted on regardless, a visual distinction can be a way of feeling responsible while changing nothing. Sometimes the honest answer is that the inferred value does not belong on that screen at all, and putting it behind a deliberate step is better design than rendering it beautifully hatched.

Grounded in

Nakatomi's treasury view, where the product is the projection rather than the ledger — a controller opens it to find out what is about to happen, not what happened.

Actuals render solid and the forecast renders hatched, so the seam between them is visible without being read about. And the balance line turns red the moment it crosses minimum need, which adds the third thing a forecast has to carry: not just what is known and what is guessed, but the one point in the guess that requires somebody to do something. A projection nobody has to act on is a chart; the threshold is what makes it a product.

Anti-patterns

• A label instead of a rendering. Present, unread, and it makes the team feel the problem is handled.
• Colour carrying certainty in a view where colour already carries category. Now neither is legible.
• Styling the regions without drawing the transition. The reader guesses where the record stopped, and guesses late.
• Precision that outruns certainty. Two decimal places on a forecast is a confidence claim made in the most trusted channel available.
• One treatment for everything inferred. "The model estimated this from four hundred records" and "the model estimated this from two" are not the same claim and should not look identical.
• A distinction that dies on export. The screenshot in the deck is where the number does its real work.

The smallest version worth building

Choose the property. Apply it to every inferred value in the view, including the ones in tables and the ones in prose. Put a rule at the seam. Round the inferred values harder than the recorded ones.

That is an afternoon, and it is the difference between a forecast a reader can calibrate against and one they will quote back to you in a meeting as though you had measured it.

Related patterns

• Mark what the product vouches for — the same question for prose claims rather than numbers: which of these does the interface stand behind.
• Answer within the boundary, and show its shape — the neighbouring case, where the gap is caused by something withheld rather than something predicted.
• Design the failure state first — a forecast that turns out wrong is a designed state, not an accident.