When a Tool Should Say “I Don’t Know” · Infinite Concept Universe · Release 1.0.0
Unknown is information
A calculator can fail while producing a perfectly formatted number. The failure happens when the interface knows less than the result pretends it knows. If a quantity is missing, a unit is ambiguous, or a cost belongs to a different time period, the most useful output may be a refusal to calculate.
That refusal is not a dead end. It is information about the model. It tells the reader which assumptions are doing real work and which inputs still need attention. In a planning tool, that distinction can matter more than a polished total.
Infinite Concept Universe adopted this rule in several recent browser tools: unknown required values remain unknown, and incompatible scope changes clear dependent inputs rather than silently reinterpreting them. This essay is about that design choice, not a claim that one interface pattern is universally best.
The danger of favorable defaults
Many planning mistakes begin with a friendly-looking default. A blank cost becomes zero. A missing pack size becomes one. A monthly fixed cost is carried into a yearly scenario without conversion. The screen stays calm because the software can still finish the arithmetic.
The user, however, has lost sight of the assumption. The interface has quietly moved from calculation into invention.
A stricter tool behaves differently. It distinguishes three states that are often collapsed into one: a value explicitly entered as zero, a category explicitly excluded from the scenario, and a value that is still unknown. Those states can lead to the same arithmetic in a narrow case, but they do not mean the same thing. Preserving the meaning makes the result easier to audit later.
Scope is part of the value
A number is rarely just a number. Ten dollars per month is not the same input as ten dollars per year. Ten square feet is not ten square meters. A price entered for one product is not evidence for another product merely because the products sit in the same comparison table.
This is why a useful calculator treats units, currency, time basis, and ownership state as part of the input rather than decoration around it. When one of those dimensions changes, dependent values may no longer be safe to reuse. Clearing them can feel less convenient than preserving them, but the interruption makes the changed meaning visible.
The same principle applies to prose. A source can support a narrow factual claim without supporting a broader conclusion. A tested software behavior can show that a calculator computes what it says it computes without proving that the business scenario entered into it will happen in the world.
Designing for revision
Planning is rarely a single pass. The first estimate is a draft; the second reflects a newly discovered constraint; the third may change because the user already owns an item or has chosen a different unit of measurement. A good small tool should make those revisions legible.
Versioned local state, exportable assumptions, visible formulas, and explicit unknowns all support the same habit: return to the plan without pretending the old context is still current. The goal is not to make uncertainty disappear. It is to keep uncertainty from hiding inside a number that looks final.
That is the useful standard for ICU's small calculators and planners: calculate aggressively when the inputs are complete, refuse clearly when they are not, and expose enough of the model that a reader can see why.