Assumption Register¶

Tracking register — instantiates Uncertainty Explicitness

A shared record of the premises a plan is betting on — each with its evidence basis, an owner, and an expiry or invalidation condition — so the beliefs holding up a decision are named and re-checked rather than silently assumed true forever.

An Assumption Register makes visible the premises a plan quietly rests on. Each row is not an event that might happen (that is a risk) nor an open question (that is an unknown) but a belief currently taken as true so work can proceed — and the register records, for each, how well-supported it is, who owns it, and the condition under which it should be revisited. Its distinguishing move is that it treats every assumption as provisional and dated: an assumption without an expiry or an invalidation trigger is exactly the kind of hidden certainty this archetype exists to prevent, so the register's discipline is to attach both to every entry.

Example¶

A startup building its first-year financial model rests on a handful of load-bearing assumptions: that paid-acquisition cost stays near its current level, that a key supplier holds today's pricing, and that a planned integration partner ships their API on schedule. Left unstated these read as facts on a spreadsheet. In the register each becomes a row with an evidence basis ("acquisition cost: three months of our own data — thin, one channel"), an owner, and an invalidation trigger ("revisit if cost rises 30% or the channel's algorithm changes"). When the ad platform changes its ranking that quarter, the trigger fires, the owner re-checks, and the model is revised before the board reads a plan built on a premise that has silently gone stale — rather than after.

How it works¶

Every entry pairs a premise with three things a bare plan omits: an evidence basis (what supports the assumption, and how strong that support is — measured, cited, or merely plausible); an owner who is responsible for it; and an update trigger (an expiry date, a threshold, or a condition change that should force a re-check). What distinguishes it from a general notes file is that these are conditions a conclusion depends on, ranked by how load-bearing and how shaky each is — so attention goes first to the assumptions that are both critical and weakly grounded.

Tuning parameters¶

Inclusion threshold — log every premise, or only the load-bearing ones. Logging everything buries the critical assumptions; logging too few reintroduces the hidden ones.
Evidence-basis rigor — a one-word tag ("measured" / "guessed") versus a graded citation. More rigor surfaces which beliefs are actually supported, at the cost of upkeep.
Expiry style — a hard date, a measurable threshold, or a named condition-change. Thresholds catch drift a calendar date misses.
Ownership grain — one owner per assumption versus a single register steward. Distributed ownership tracks better but needs a steward to stop rot.
Review coupling — whether register review is tied to existing plan gates or run on its own cadence.

When it helps, and when it misleads¶

Its strength is that it converts silent premises into dated, owned bets — the failure most plans share is not a wrong assumption but an unexamined one, and the register is where an assumption goes to be examined and re-examined.^[1] Its failure modes: it can fill with trivially-true premises until the dangerous one is lost in the noise; expiry dates get rubber-stamped forward without a real re-check; and it can be written to look diligent rather than to genuinely stress the plan. It also cannot record the events that might go wrong regardless of any premise. The discipline that keeps it honest is the invalidation trigger with teeth: a re-check that can actually change the plan, tied to a real threshold, owned by someone accountable — not a date that is silently extended each quarter.

How it implements the components¶

assumption_log — this is the register's core: the enumerated premises a conclusion depends on, each with the condition that would invalidate it.
evidence_quality_trace — each entry records what supports the assumption and how strong that support is (measured versus judged, current versus stale, one source versus many), so a confident-sounding premise cannot hide thin backing.
update_trigger — the expiry date or invalidation condition on each row specifies exactly what should force the assumption to be revisited.

It does not size or route adverse events (uncertainty_source_inventory, decision_threshold_link, escalation_or_review_rule) — that is Risk Register — and it does not grade a body of evidence into a certainty rating, which is Evidence Grade Rubric.

Instantiates: Uncertainty Explicitness — the register keeps a plan's hidden premises visible, supported, and dated.
Sibling mechanisms: Risk Register · Model Limitations Card · Known Unknowns Log · Caveated Decision Memo · Evidence Grade Rubric · Forecast Range · Confidence Interval · Confidence Label · Error Bar · Probability Estimate · Uncertainty Band

Notes¶

The register is only alive if the invalidation triggers are actually watched. A common anti-pattern is a rich register created at project kickoff and never opened again — at which point it documents the assumptions the team had rather than the ones it is currently betting on. Couple review to a cadence or a plan gate, or it becomes an artifact of history.

References¶

[1] Assumption-Based Planning is the named practice of building a plan around its explicit load-bearing assumptions and defining "signposts" that warn when one is failing — the same logic the register operationalizes at the row level with evidence bases and invalidation triggers. ↩