Known Unknowns Log¶
Tracking register — instantiates Uncertainty Explicitness
A running list of the questions you know you cannot yet answer — each tied to what it would change, who is chasing it, and the point at which not knowing must block or escalate the decision — so open gaps stay named instead of dissolving into a confident summary.
A Known Unknowns Log keeps the unresolved questions of a project visible: the things the team knows it does not yet know.[n1] Its distinguishing move among its siblings is that it tracks absence of knowledge rather than any representation of knowledge — not how uncertain an estimate is, nor a premise being bet on, nor an adverse event that might occur, but a specific open question with no answer yet. And it refuses to let that gap be cosmetic: each entry is tied to what the answer would change, who is responsible for resolving it, and — critically — the point at which continuing to not know it must block the decision or escalate rather than be quietly tolerated.
Example¶
A team running due diligence on an acquisition maintains a known-unknowns log alongside its findings. One entry: "we have not confirmed whether the target's largest customer contract auto-renews or expires next year." It is not a risk (an event) or an assumption (a bet) — it is a question with no answer. The log ties it to consequence ("if it expires, roughly a third of projected revenue is at risk"), an owner (the commercial lead), a resolution path ("obtain the contract; if withheld, ask in the management session"), and a decision threshold: "this must be resolved before signing — it is not tolerable to close blind." When the seller stalls, the escalation rule sends it up rather than letting the deal drift toward signing with the question still open. The log is what stops a polished diligence summary from reading as complete when a revenue-defining question is still blank.
How it works¶
Each entry is an open question, made actionable by four attachments the archetype prose calls for: a consequence (what turns on the answer), an owner and resolution path, a decision threshold (what confidence or answer is needed before the dependent decision may proceed), and an escalation or tolerate rule (when an unresolved unknown must go up, and when it may be explicitly accepted with reasons). What distinguishes it from a to-do list is that its items are epistemic gaps ranked by decision impact, not tasks — and each carries an explicit answer to "what happens if we still don't know this when we have to decide?"
Tuning parameters¶
- Scope threshold — log every open question versus only the decision-relevant ones. Logging all of them buries the few that actually gate the decision.
- Consequence linkage — each unknown tied to a specific downstream decision versus left free-floating; the linkage is what separates a live log from a wish-list of curiosities.
- Blocking vs tolerable — which unknowns must be resolved before proceeding and which may be accepted with a stated reason; over-blocking stalls everything, over-tolerating reintroduces hidden gaps.
- Resolution ownership — a named owner and path per unknown versus a shared pile nobody chases.
- Escalation trigger — the age, consequence, or approaching decision date at which an unresolved unknown is forced upward.
When it helps, and when it misleads¶
Its strength is that it keeps a summary from lying by omission: a clean deck or a confident memo can imply completeness precisely because the gaps have gone unrecorded, and the log is where those gaps are held, owned, and gated. Its failure modes are real. It can only hold the known unknowns — by construction it is silent about the unknown unknowns, and a full-looking log can breed false confidence that everything important has been anticipated. It can also fill with trivial open questions that drown the decision-critical one, or become a graveyard where unknowns are logged and never chased. And a "tolerate" note can be used backwards to wave through a gap someone would rather not resolve. The discipline that guards against this is the decision threshold and the escalation rule: every unknown must answer "what if we still don't know this at decision time?", and blocking unknowns must actually block.
How it implements the components¶
known_unknowns_registry— this is the log's core: the enumerated open questions, missing observations, and unresolved dependencies, each tied to consequence and owner.decision_threshold_link— each entry states what answer or confidence is required before the dependent decision may proceed, turning a gap into action logic (resolve, hedge, or accept).escalation_or_review_rule— its escalate/tolerate rule routes an unresolved, consequential unknown upward rather than letting it be silently absorbed.
It does not represent how uncertain a known estimate is (confidence_representation) — that is Confidence Interval and Confidence Label — nor does it log the premises the plan is betting on (assumption_log), which is the Assumption Register.
Related¶
- Instantiates: Uncertainty Explicitness — it keeps decision-relevant gaps in knowledge visible, owned, and gated.
- Sibling mechanisms: Assumption Register · Risk Register · Caveated Decision Memo · Model Limitations Card · Evidence Grade Rubric · Confidence Interval · Confidence Label · Forecast Range · Error Bar · Probability Estimate · Uncertainty Band
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Known Unknowns Log operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it a running list of the questions you know you cannot yet answer — each tied to what it would change, who is chasing it, and the point at which not knowing must block or escalate the decision — so open gaps stay named instead of dissolving into a confident summary
Independent corroboration: The frozen evidence defines Known Unknowns Log as 'A running list of the questions you know you cannot yet answer — each tied to what it would change, who is chasing it, and the point at which not knowing must block or escalate the decision — so open gaps stay named instead of dissolving into a confident summary', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Project and decision management developed issue logs that assign owners and escalation points to unresolved questions.
Related originating lineages:
- Engineering & Design — Systems engineering contributed decision gates and escalation thresholds for unresolved assumptions.
- Futurism & Strategic Foresight — Strategic uncertainty practice independently developed explicit inventories of known unknowns.
- Security Studies & Intelligence Analysis — Intelligence analysis materially shaped naming gaps by decision consequence and collection ownership.
Review resolution: Both independent reviews place the primary lineage in organizational_management. The queued differences (alternate_origin_disagreement, origin_mode_disagreement, domain_reach_disagreement) concern secondary metadata rather than primary provenance. The final retains futurism_foresight, security_intelligence, engineering_design only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=universal records application breadth separately. encyclopedia_synthesis=true reflects whether either reviewer identified a corpus-specific synthesis, and confidence=medium preserves the more cautious evidence assessment.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
The log sits between two siblings and is easy to blur with them. A known unknown is an open question (no answer yet); an assumption is a question you have chosen to answer provisionally and bet on; a risk is an adverse event that might occur. The same fact can migrate: an unknown, once you decide to proceed as if the answer is X, becomes an assumption — and should move from this log to the Assumption Register, not sit in both.
[n1] The "known unknowns" phrasing — things we know we do not know, distinct from "unknown unknowns" we have not even thought to ask — is the standard taxonomy this log operationalizes; the mechanism's honest boundary is that it can only ever hold the former. ↩