Assumption Log¶
Living artifact — instantiates Dependency Exposure
Makes the unstated premises a plan silently rests on into an explicit, revisable list — each with its confidence and a trigger to revisit it when reality drifts.
Most dependency work maps things a system relies on — suppliers, services, roles. The Assumption Log targets the dependency that has no node on any diagram: the premise. A forecast, budget, policy, or model doesn't just depend on components; it depends on conditions holding true — that demand stays flat, that the grant renews, that the API keeps its current behavior. The log's one distinguishing move is to make each such premise a first-class, written entry, tagged with how confident anyone actually is in it and with an explicit condition under which it must be re-checked. It converts "we're assuming that…" — usually said once and forgotten — into a standing object someone can audit, challenge, and watch.
Example¶
A hardware startup builds an 18-month runway plan. On the surface it's a spreadsheet of costs and hires; underneath it rests on premises nobody wrote down: that the seed round's terms let them raise a bridge if needed, that their contract manufacturer holds the quoted unit price, and that the founding engineer stays through launch. The Assumption Log pulls each into the open as an entry: "CM unit price holds at ≈$42 through Q3 — confidence: low, basis: verbal quote, revisit-if: PO not signed by March." The most fragile premise — the unsigned manufacturing price — now has a confidence tag that screams and a trigger date attached.
When March arrives with no signed PO, the trigger fires and the premise is re-opened before it silently blows a hole in the runway, rather than after. The log didn't prevent the risk; it kept a load-bearing guess from hardening into an unexamined fact.
How it works¶
The log inverts the usual object of attention: it records premises, not entities. Each entry carries a plain-language statement of the assumption, a confidence level, a one-line basis (where the belief comes from), the condition under which it would be invalid, and a revisit trigger or date. It stays alive — entries are promoted to confirmed, retired, or flagged as breaking, and the list is worked, not archived. Its whole value is in the entries that turn out wrong: the log is the place a broken premise surfaces early instead of as a downstream surprise.
Tuning parameters¶
- Assumption threshold — how small a premise earns an entry. Log too little and the load-bearing guesses hide; log everything and the two or three that matter drown in trivia.
- Confidence scale — coarse (high/med/low) versus a calibrated probability. Finer scales sharpen triage but invite false precision on things nobody can really quantify.
- Trigger sensitivity — how tight the revisit condition is set. Tight triggers catch drift early but fire noisily; loose ones stay quiet until it's late.
- Review cadence — whether the whole log is swept on a schedule or only entry-by-entry on triggers. A periodic sweep catches assumptions whose trigger was mis-specified.
- Ownership — whether each entry names someone accountable for testing it, or the log is collectively (i.e., un-)owned.
When it helps, and when it misleads¶
Its strength is catching the failure mode diagrams can't: a plan that is internally sound but resting on a premise that quietly stopped being true. Because entries carry triggers, a drifting assumption announces itself instead of detonating downstream.
Its classic decay is the graveyard list — a log built once for a planning ritual and never revisited, so stale premises acquire the false authority of having been "documented." Two related misuses: padding it with trivial assumptions until the load-bearing ones are invisible, and running it backwards — writing down assumptions after a decision to make it look rigorous rather than to test it. The discipline is to attach a real owner and trigger to every entry, mark which few are load-bearing, and treat the log as a working instrument. It is not a risk register: a risk is a potential harm, an assumption is a belief currently treated as fact[n1] — the log's job is to keep those beliefs falsifiable.
How it implements the components¶
assumption_record— its core output: each premise captured as an explicit statement with a confidence tag and basis, so it can be examined instead of assumed.freshness_review_cadence— every entry carries a revisit schedule or date, so no assumption is allowed to silently rot into fact.dependency_change_trigger— the invalid-if condition on each entry fires when reality diverges, flagging the premise for re-validation before it fails downstream.
It does not record the depends-on relations among concrete components — that is Dependency Graph — nor rank and own the full dependency set (Dependency Registry) or model how a failure propagates (Impact Analysis).
Also instantiates¶
Cautious Pattern Completion — A different problem from a plan's drifting premises: here a coherent whole has been inferred from fragments — an incident timeline, an early diagnosis, a reconstructed design rationale — and risks being mistaken for observed fact. The Assumption Log separates the inferred connective tissue from the evidence: each bridging premise ("we're assuming the allergy flag was cleared by an import overwrite, not a clinician edit") becomes an explicit entry with what would confirm or break it, so the completion stays falsifiable instead of self-sealing. The load-bearing guesses that turn fragments into a story are kept visible rather than laundered into certainty.
assumption_marker— each entry names an inferred link, default, or prior used to connect the partial input to a candidate completion, separating assumption from observed evidence.missing_evidence_marker— the basis and revisit-if fields identify the specific observation that would confirm, reject, or narrow the completion, keeping it from becoming self-sealing.uncertainty_label— the confidence tag travels with the completion wherever it is used, marking inferred content as inferred rather than observed.
Regress Termination Rule — Here the problem is an unbounded justification chain — every premise inviting a prior "why accept that?" — that blocks a decision or hides its real stopping point behind fatigue or authority. The Assumption Log is the accountability artifact of a local, explicit closure: when a team decides that, for this decision and these stakes, a premise will be treated as enough, the log records the accepted base, what depends on it, what remains uncertain, and what would reopen the chain. This differs from tracking a plan's live premises — its job is to make an act of stopping visible, contestable, and reopenable, so action proceeds on a named foundation rather than a tacit one.
foundational_assumption— each entry is a premise accepted provisionally as a base for current action, held visible and contestable instead of buried inside the decision.assumption_record— the log documents the accepted base, why it was accepted, what depends on it, what stays weak, and who owns future review.reopening_condition— the revisit trigger specifies what — new evidence, changed stakes, an observed failure — would force the closed chain back open.
Structured Sensemaking — In an ambiguous, fast-moving situation a group must build a shared but revisable interpretation to coordinate, and the danger is that a provisional narrative hardens into an overconfident official story as it travels. The Assumption Log operationalizes that loop's uncertainty register: it records which claims the working narrative depends on, the confidence in each, and the test that would update it, so a crisis briefing or weak-signal read carries its caveats across shifts and forums rather than losing them. The distinct angle is coordination under shared ambiguity, not one planner's private premises.
assumption_and_uncertainty_register— the log is the concrete form of this component, holding the assumptions, confidence levels, and unresolved questions beneath the provisional narrative.revision_loop— each entry's test or trigger feeds new evidence back into the interpretation, making revision the expected update rather than an embarrassment.
Related¶
- Instantiates: Dependency Exposure — the Assumption Log realizes the archetype's assumption-focused variant, exposing premises rather than components.
- Sibling mechanisms: Dependency Registry · Dependency Review Workshop · Dependency Graph · Architecture Dependency Review · Contract and SLA Review · Critical Dependency Dashboard · FMEA Dependency Table · Impact Analysis · Software Bill of Materials · Supply Chain Mapping · Vendor Risk Map
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: The mechanism maintains dated premise entries with confidence, basis, invalidation conditions, revisit triggers, and evolving confirmed, retired, or broken status, so its operative form is an accumulating decision-support record.
Nearest alternative: Representation, Specification & Plan — The list externalizes assumptions, but its entries and statuses evolve with actual evidence and preserve the history of premise governance.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: The assumption log is a named project-management artifact, maintained separately from the risk register in PMBOK-style practice.
Related originating lineages:
- Engineering & Design — Systems engineering uses assumption tracking to govern designs whose dependencies and environments may drift.
- Futurism & Strategic Foresight — Foresight methods formalized critical-assumption tracking against emerging evidence.
Review resolution: Organizational project governance is the agreed primary lineage. Engineering decision logs and foresight assumption monitoring independently contribute traceability and revision triggers, supporting a convergent classification without implying an Encyclopedia-created form.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The log is only as honest as its confidence tags. Its most valuable entries are the low-confidence, high-consequence ones — precisely the premises people are most tempted to quietly upgrade to "fact" to avoid dealing with them. Guarding that temptation is the whole discipline.
[n1] The distinction between an assumption and a risk is standard practice in project management — an assumption log is a named PMBOK artifact, kept separately from the risk register precisely because a premise treated as true and a hazard treated as possible need different handling. ↩