A Field Guide to Useful Uncertainty

Chapter 1 · Name the decision

Every useful plan begins by shrinking the question. “What should I do?” is too large. “How much paint should I buy for these four walls, given this coverage assumption and two coats?” is small enough to model. “Can this business work?” is too large. “At this price and these entered costs, how many completed jobs would cover the fixed costs in this scenario?” is answerable.

The smaller question does not solve the larger life decision. It gives the decision a handle.

Start by writing one sentence that names the output you actually need. Then write a second sentence naming what the output cannot tell you. The second sentence is not a disclaimer added at the end; it is part of the design. It prevents the model from quietly becoming a prophecy.

A useful decision statement has three pieces: the action under consideration, the scope of the estimate, and the boundary of the evidence. “Estimate paint volume for this room from entered dimensions; do not infer surface condition or manufacturer-specific coverage.” “Estimate break-even units from entered price and cost assumptions; do not infer demand.”

Once the decision is narrow, the rest of the tool can be honest without becoming vague.

Chapter 2 · Separate known, chosen, and unknown

A planning model mixes different kinds of information. Some values are observed: a room is twelve feet long. Some are chosen: the user wants two coats. Some are assumptions: one container is expected to cover a certain area. Some are unknown: the user has not priced a required material yet.

Problems begin when the interface stores all four as if they were equally certain.

Label them instead. Known values can carry a source or measurement note. Chosen values can be described as preferences. Assumptions can be editable and grouped in one place. Unknowns can remain visibly incomplete.

This classification changes the way a person reads the result. A total built mostly from measured dimensions feels different from a total built mostly from guessed prices. The arithmetic may be equally correct in both cases, but the decision confidence should not be.

The simplest implementation is often enough: do not prefill uncertain money values; show “unknown” rather than zero; and add a short assumption summary beside the result. The summary is a compact map of what the number depends on.

Chapter 3 · Make incompatible changes expensive in the right way

Interfaces often optimize for preserving input. That instinct is usually helpful, but preservation can become dangerous when the meaning of an input changes.

Imagine a room estimator with dimensions entered in feet. If the user switches the unit system to meters, keeping the same numerals silently changes the room. A business tool can make the same mistake if a fixed cost entered “per month” remains in place after the time basis changes to “per year.”

The safe response is not always automatic conversion. Automatic conversion is appropriate only when the software knows what the old value means and the mapping is exact. When the scope itself has changed, clearing a dependent value and asking for confirmation may be more truthful.

This is a useful kind of friction. It interrupts the user precisely where an old assumption could masquerade as a new one.

The rule is simple: preserve inputs when their meaning is stable; convert when the conversion is explicit and reversible; clear when the meaning is ambiguous. Record the reason in the interface so the user does not experience the reset as random data loss.

Chapter 4 · Let the result show its work

A result is easier to trust when it can be reconstructed. This does not require exposing source code. It requires exposing the model.

For a calculator, show the formula in ordinary language, the units that enter it, and the intermediate quantities that matter. For a checklist or planner, show how quantities were derived. For a comparison, separate verified facts from editorial judgment. For a reading or research resource, distinguish sourced claims from interpretation.

When the model is visible, disagreement becomes productive. A reader can say, “I would use a different waste allowance,” or “This fixed cost belongs outside the scenario,” instead of rejecting an unexplained total.

Visible formulas also make revision easier. The user can change one assumption and understand which part of the output should move.

The goal is not to make every page look like a spreadsheet. The goal is to make the chain from input to output inspectable.

Chapter 5 · Save the context, not just the answer

A saved result without its assumptions is a souvenir. It may remind you what the screen once said, but not why it said it.

Portable local state should therefore include the inputs, units, version information, and enough metadata to interpret the result later. If a newer version changes the schema or formula, old state should not be overwritten blindly. A migration can be explicit when it is safe; otherwise the old state should remain protected until the user chooses what to do.

This is especially important for small tools because they are easy to revisit months later. The user may remember the number and forget the conditions.

A useful export is not a promise of permanent compatibility. It is a record of the scenario at a point in time. Include a version, a timestamp, and a readable summary. Treat future versions as new contexts rather than pretending every old value still fits.

Chapter 6 · Stop at the evidence boundary

A model can be complete and still be limited.

A break-even calculator can correctly compute contribution margin from entered assumptions without proving that customers will buy at the entered price. A room estimator can correctly compute area without knowing whether a wall needs special preparation. A route planner can generate a sequence without physically inspecting the location.

The discipline is to stop exactly where the evidence stops. Say what has been demonstrated: the software behavior, the arithmetic, the file integrity, the browser interaction. Then say what remains outside the test.

This boundary keeps a useful tool useful. It prevents the desire for a confident answer from turning a planning aid into a false claim about the world.

Uncertainty is not the enemy of a decision. Hidden uncertainty is. A small model earns trust by making its unknowns as legible as its outputs.