Model Assumptions Log¶
Artifact — instantiates Implicit Assumption Surfacing
A record of assumptions, evidence status, owners, validity conditions, and review triggers.
Model Assumptions Log is the standing artifact — a living register — that holds assumptions after they have been surfaced, so they can be governed over time rather than forgotten. It surfaces nothing and tests nothing; its whole value is persistence. Each entry pins an assumption alongside the fields that keep it honest: how well the evidence actually supports it, who is accountable for it, the conditions under which it still holds, when it must be revisited, and the history of how it has changed. Without such a record, a surfaced premise silently hardens into an unexamined fact — the archetype's reification failure — because nobody is holding the receipt that says "this was a judgment call, made on this evidence, valid only under these conditions." The log is that receipt, kept alive.
Example¶
A city water utility runs a demand-forecast model that drives twenty-year capital planning. One entry in its assumptions log reads: "Per-capita water demand continues declining ~1%/year." Beside it sit the fields that matter. Evidence status: moderate — fits the 2015–2024 metered trend, but the mechanism (fixtures, pricing, conservation) is only partly understood. Owner: the Planning lead. Validity condition: holds while no large industrial customer arrives and pricing structure is unchanged. Review trigger: each budget cycle, and immediately on any major new-connection request. When a semiconductor fab announces a plant that would draw more than the whole residential base, the trigger fires. The assumption is revised, the forecast is rerun, and the log preserves both the old row and the new — so a future planner can see not just what the model now assumes but why it changed and when. The premise never got to masquerade as a permanent fact.
How it works¶
- One row per assumption. The statement itself, kept as a proposition, not a theme.
- Attach the governance fields. Evidence/confidence status, accountable owner, validity condition, and the review trigger or cadence.
- Log changes, never overwrite. Revisions append; the prior state stays visible, building a history.
- Wire triggers to the calendar and to events. Some rows review on a cadence; others fire on a named event.
The distinguishing property is that it is a persistence layer — a database of premises with their status and history — not a meeting, a reasoning move, or an act of elicitation. It is where the outputs of the surfacing mechanisms come to live.
Tuning parameters¶
- Granularity — how many assumptions get logged. Log everything and the register becomes a swamp nobody reads; log too few and the quietly critical premise never makes it in.
- Confidence scheme — traffic-light tags vs. explicit probabilities vs. evidence-tier labels. Coarser schemes are cheap and legible; finer ones support real weighting but invite false precision.
- Review cadence — calendar-driven vs. event-triggered vs. both. Calendar review guarantees attention; event triggers catch the shock the calendar would miss.
- Visibility — private working doc vs. published register. Publishing exposes premises to challenge and improves accountability but can chill candor about weak evidence.
When it helps, and when it misleads¶
Its strength is that it prevents reification-by-forgetting: a premise stays flagged as a judgment with a confidence and a boundary, and a live owner is on the hook to revisit it when the trigger fires. It is what turns "we surfaced our assumptions once" into an assumption that is actually watched.
Its honest failure mode is the graveyard: a write-once register nobody reviews, whose stale rows lend false confidence precisely because they are written down — the reification the log was meant to prevent, now dressed as diligence. The classic misuse is audit-checkbox logging: owners named but not watching, triggers defined but never fired. The guarding discipline is that every row must have a live owner and a real trigger, and that dead assumptions get pruned; a register is only as honest as its most recent review. The mature form of this artifact is the project-management assumption log — a living register kept exactly so premises do not silently harden into fact.[n1]
How it implements the components¶
confidence_marker— each row carries the evidence status that keeps the assumption from being read as fact.assumption_owner— every assumption is assigned an accountable owner.validity_condition— the row records the boundary within which the assumption holds.update_or_documentation_rule— the review trigger and cadence that govern when the premise must be revisited.assumption_trace— the append-only history preserving how a premise evolved and why.
It records; it does not produce. It does not elicit or name the premises (implicit_assumption), test them against evidence (evidence_test), flip them (alternative_assumption), or find who a design leaves out (excluded_case) — those are the jobs of the surfacing, testing, and critique siblings, whose outputs the log stores.
Related¶
- Instantiates: Implicit Assumption Surfacing — the log is the artifact that keeps surfaced assumptions inspectable and monitored over time.
- Consumes: the premises produced by reflective_interview, design_critique, premortem_assumption_probe, and red_team_assumption_review — it holds what they surface.
- Sibling mechanisms: counterfactual_assumption_test · design_critique · premortem_assumption_probe · red_team_assumption_review · reflective_interview · stakeholder_assumption_elicitation · assumption_audit
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Model Assumptions Log operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it a record of assumptions, evidence status, owners, validity conditions, and review triggers.
Independent corroboration: The frozen evidence defines Model Assumptions Log as 'A record of assumptions, evidence status, owners, validity conditions, and review triggers', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Systems engineering formally records assumptions throughout the model lifecycle; organizational ownership and statistical diagnostics support revision but are not merely application venues. This establishes engineering_design as the primary origin lineage rather than merely a domain where the mechanism is now applied.
Related originating lineages:
- Organizational & Management Science — Assumption and constraint logs are established project- and risk-management artifacts with owners and review points.
- Statistics & Experimental Design — Statistical modeling contributes explicit assumption checking and scope conditions.
Review resolution: Authoritative/primary-source research resolves the conflicting primary-origin claims in favor of engineering_design: Systems engineering formally records assumptions throughout the model lifecycle; organizational ownership and statistical diagnostics support revision but are not merely application venues. Retained alternate origins (organizational_management, statistics_experimental_design) are limited to independently formative or materially shaping lineages supported by the reviewer evidence; downstream adoption alone was not promoted to origin. The breadth of present-day use is recorded separately as domain_reach=multi_domain. origin_mode=cross_disciplinary_synthesis, confidence=medium, and encyclopedia_synthesis=false reflect the surviving provenance evidence and the encyclopedia's generalization.
Attribution caveat: Closely related assumption logs exist independently in modeling, safety, and project disciplines.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
- NASA Systems Engineering Handbook — Documents model boundaries, assumptions, interfaces, decomposition, verification, and lifecycle revision in systems engineering.
Notes¶
The log is a standing record, not a point-in-time sweep — that is the line between it and assumption_audit. An audit walks a whole plan once and triages its premises by consequence; the log is the ledger the audit's "watch later" verdicts are handed to, and the place they are kept alive between audits.
[n1] An assumption (and constraint) log is a standard project-management artifact — a living register of assumptions with owners and review points — maintained precisely so that premises do not silently harden into unexamined fact. Its existence in mature practice is the reason the graveyard failure is a discipline problem, not a design one. ↩