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^[1] — 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).

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

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.

References¶

[1] 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. ↩