Information that cannot be acted on is noise

What it is

Under the generate box hang per-token probabilities. The user cannot change temperature, cannot ban a word, cannot spend those numbers on whether to send. The figures occupy space on the screen and enter no act. Information that cannot be acted on is noise: not a neutral “knowing a bit more,” a surplus signal in the interference channel.

The test of noise is action, not truth. The numbers can be wholly true and still be noise.

Why it happens

People try to find a use for every number they see. When they cannot, they either ignore it (the display was wasted) or invent a use (read token probability as accuracy, and send). The latter is worse than ignoring. Noise therefore harms in two ways: it occupies, and it is misused.

“Cannot be acted on” is relative to the current set of controls. The same probability, if the interface offers “generate again with less randomness,” can become grounds for action; without the control, it is still noise. Action first, then information that earns a place. Not dump information and hope the user invents an action.

Studying it

On a fixed control set, add a class of internal quantity that is true but unusable; watch decision time, misuse (treating it as accuracy or as a checklist that must be verified), and decision quality. Independent variables: whether the internal quantity is shown, whether a control that can consume it is also given. Dependent variables: time spent, misuse count, agreement of the decision with baseline.

If adding a control that consumes it drops misuse and raises quality, it was noise, not “transparency itself is harmful.”

Where it stops holding

An audit log is noise to the operator on the spot and grounds for action to an investigator later — change the audience and the noise identity lifts. If the user copies the information out of the system to use it (putting probabilities in a paper’s method), that is an act outside the product; inside the product it may still count as noise unless the product promises to support that use. This entry only judges the identity of leftover information. The purpose of transparency, and the test of whether there is enough, are neighbouring entries.

Applying it

• Beside each piece of copy, ask which control or executable sentence it corresponds to. If none, delete it, or add that control.
• Internal quantities stay out of the person’s interface by default. When engineering needs them, use another surface.
• If you find users inventing a use (screenshotting probabilities as accuracy), either supply a real hit rate or take the quantity away.
• Check: point at every block of copy and ask “what can you do with this.” Those answered “just look” are noise; count how much on-screen area they occupy.

Related

• Same group: L5.05.1 Excess technical detail does not produce understanding · L5.05.2 Transparency must serve the user's next decision · L5.05.4 Transparency is sufficient only if the user can change the next action from it · L5.05.5 Excess detail crowds out attention needed for key information · L5.05.6 Transparency and usability are in tension; full disclosure makes the interface unusable · L5.05.7 Transparency does not necessarily produce trust; exposing complexity can lower it · L5.05.8 Different roles should receive different depths of explanation, not the same text
• Nearby: L5.02 Local and Global Explanations · L5.08 Counterfactual Explanations · L1.08 Confidence Displays and Their Misreadings
• Search terms: unactionable information · noise · actionable explanation