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.[n1] 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.
Also instantiates¶
Assumption Stress Testing — The primary facet surfaces silent premises so they can be examined; this facet persists the output of deliberately breaking them. Assumption Stress Testing takes a plan that looks robust only because its premises stayed in the background, reverses or strains each key one to see what fails, and needs somewhere to record the result — and the Assumption Register is that governance artifact. It holds each assumption alongside its criticality, the failure mode a break test exposed, the safeguard now guarding it, and the trigger watching it, so a one-time stress workshop becomes a live record rather than theater.
assumption_inventory— the register is the structured view that pulls explicit and implicit assumptions out of scattered slides and models into one place the stress test can work from.criticality_filter— each row's load-bearing-and-shaky ranking is exactly the filter deciding which assumptions earn real stress testing.monitoring_trigger— the invalidation condition on each entry is the signal that a stressed assumption is weakening after commitment.assumption_owner— the owner field keeps each tested premise watched, so the stress test does not decay into a single workshop.
Problem-Distribution Fit Selection — A different subject entirely: choosing a method — algorithm, model, heuristic, policy — whose built-in bias matches the cases it will actually face, where the hazard is that a method's assumptions (stationarity, independence, a stable case mix) quietly stop holding as the environment shifts. The Assumption Register here names and dates those method assumptions rather than a plan's business premises: it records what each chosen method requires to be true, how well-supported that requirement currently is, and the drift condition that should force re-selection — so a model matched to yesterday's cases is not still trusted after the distribution moves.
assumption_contract— each row states what must be true for the chosen method's bias to be useful — stationarity, independence, noise, cost structure — made explicit instead of buried in the method.distribution_shift_sentinel— the invalidation trigger doubles as a drift watch, firing when the case mix, incentives, or objectives change enough to undermine the original fit evidence.
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: 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, making its operative form a durable account of actual events, decisions, or transitions whose value depends on history or provenance.
Independent corroboration: The frozen evidence defines Assumption Register as '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', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: A named, owned, status-tracked assumption register is fundamentally a project and organizational governance artifact.
Related originating lineages:
- Engineering & Design — Requirements and design reviews track assumptions whose failure changes feasibility or validation.
- Futurism & Strategic Foresight — Assumption-based planning contributes load-bearing assumptions, signposts, and hedging responses.
Review resolution: RAND defines assumption-based planning around identifying load-bearing assumptions, monitoring signposts, and preparing shaping or hedging actions. The page combines that lineage with the ordinary managerial register form; because ownership, status, review, and action routing define the artifact, organizational management is primary.
Attribution caveat: Project-management registers and assumption-based planning developed closely related practices, but the persistent register artifact is managerial while foresight supplies its monitoring logic.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- RAND — Assumption-Based Planning and Army Planning
- Cambridge University Press — Assumption-Based Planning Sample
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.
[n1] 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. ↩