Uncertainty must be expressed, not hidden

What it is

The model’s answer to “will it rain tomorrow” or “is this the same author” is a distribution. The interface often answers with a point: rain, yes. The point wipes the rest of the mass. Uncertainty must be shown means the part of the spread a decision can use has to sit beside the result as a first-class object, not wait for the user to guess “does this look certain.”

Hiding is not neutral. Not drawing the spread is claiming the spread is zero.

Why it happens

Clean declarative sentences are read as high conviction. That is a default of language, not a user failing to be rational. Decoding can keep logits, entropy, ensemble disagreement inside; the product pipeline then argmaxes or takes a mode and typesets that one value as the answer. Internal uncertainty is thrown away at the boundary.

Once thrown away, downstream can only act as if the matter were settled: roster, order, cite. When the error is found, no one can point to the system having been torn between two possibilities — the tear never left the model, it only never left the server. Work on uncertainty visualization argues the same: if you do not draw, decision makers fill with their own prior, usually too narrow.

Studying it

The same prediction, point estimate versus a display with spread (frequency bar, fan, interval, small multiples). The decision task needs real payoff: take an umbrella, review, submit. Independent variables: presence of an uncertainty encoding, channel (position / colour / words). Dependent variables: decision calibration, overconfidence, time on task.

“Users say they prefer a certain answer” is not a reason to hide. Preference often opposes calibration. Report decision quality, not satisfaction.

Where it stops holding

When the spread is negligible relative to the action threshold (99% versus 1%, and the action flips at 50%), forcing a display becomes noise. Playful generation (one joke line) has no decision threshold, so uncertainty is not an object that must be encoded. In safety settings, drawing uncertainty as “maybe safe” can be more dangerous than hiding; a conservative point plus a clear “undecided means forbidden” is the better encoding. This entry only argues for showing by default. Grain of the encoding, and the fraud of extra decimal places, are the other two cards in the group.

Applying it

• Any output someone will use to say yes/no or which-one gets an uncertainty mark at that decision’s grain: possible / likely / an interval, not a bare label.
• Do not imply certainty with a heavier stroke or a fuller bar — that is lying with visual weight.
• If the internals have no usable uncertainty signal, write “cannot estimate how sure,” rather than forging a smooth confidence bar.
• Check: strip every uncertainty encoding and ask “how sure is the system.” If answers pile up at extreme certainty and entropy on that item is high, hiding is already manufacturing a false point estimate.

Related

• Same group: L1.03.2 The expression must match the granularity of the user’s decision · L1.03.3 Over-precise numbers manufacture false certainty
• Nearby: L1.04 Presenting confidence · L1.08 Confidence displays and their misreadings · L5.03 Trust calibration
• Search terms: uncertainty visualization · suppressing uncertainty · point-estimate bias