Recorded Assumption

Every decision made under uncertainty rests on an assumption. The assumption is usually not written down, so when it stops being true nobody notices, and the design continues to be defended on grounds that no longer hold.

A recorded assumption states it explicitly with a trigger: "we are assuming fewer than five thousand tenants; if we exceed two thousand we revisit the tenancy model."

Why it matters

That single sentence is frequently worth more than the analysis around it, because it is the only part that remains actionable. It converts an invisible dependency into a monitored one, and it tells a future reader — who may be a different person entirely — what to watch for.

It also protects the decision. A choice defended by "it was right given what we assumed, and here is the assumption" survives scrutiny in a way that an undefended choice does not.

Implementation patterns

• State the assumption as a fact about the world, not as a preference: a scale, a rate, a customer commitment, a regulatory position.
• Attach a threshold that is measurable, and where possible monitored — so the invalidation is detected rather than remembered.
• Record it with the decision rather than separately, since a register of assumptions divorced from decisions is not consulted.
• Prefer the option that preserves the most future choices when uncertainty is high, since the value of optionality rises with uncertainty and a slightly worse reversible option beats a slightly better irreversible one.
• Stage the commitment: much of what feels like one decision is several with different information needs, and the smallest decision that unblocks progress is frequently sufficient.
• Buy information cheaply where possible — a spike, a prototype, a customer conversation. A week of evidence frequently resolves what six months of deliberation would not.

Industry example

Developer-tools companies such as Postman make many decisions on assumptions about how customers will use a capability, which cannot be known before shipping. The practice that distinguishes teams that adapt well is not better prediction but explicitly recorded assumptions with revisit triggers, so that when usage diverges from expectation the design is reconsidered deliberately rather than accreting workarounds.

Failure scenarios

• Unstated assumptions, so invalidation is invisible.
• Assumptions stated without thresholds, which cannot be evaluated.
• A separate assumption register, which is never read.
• Deferring past the last responsible moment, so circumstance decides.
• Choosing maximum flexibility regardless of cost, producing a design that is expensive and mediocre at everything.

Trade-offs

Recording assumptions makes a decision look less confident, which is uncomfortable in a document intended to persuade — and some stakeholders read acknowledged uncertainty as weakness.

The framing that resolves it: "we are deciding X now because deferring costs Y, and deferring Z because the information arrives in March." Separating what is decided from what is deferred makes the uncertainty visible without appearing indecisive, and it sets the expectation that a revisit is planned rather than a failure.

Interview question

"Take a design decision you made in the last year. What were you assuming, what would have told you the assumption was wrong, and would you have noticed?"