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

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

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.

References¶

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