What is Decision Log?
A decision log is a durable record of material choices made during a project, product, operation, or governance process. It captures what was decided, who had decision authority, when the decision became effective, the context and alternatives considered, the rationale and evidence that mattered, and any conditions or follow-up created by the choice.
What good decision log looks like
A strong decision log prevents teams from repeatedly reconstructing why a choice was made. It distinguishes a final decision from a recommendation or open question, preserves the key rationale without reproducing every discussion, records conditions and superseded decisions, and links follow-up actions or implementation work.
- Give each material decision a stable identifier and clear decision statement.
- Record decision date, effective date when different, decision owner or authority, and status such as proposed, approved, superseded, or reversed.
- Summarize the problem or choice and the criteria that mattered.
- Record alternatives considered and the evidence or tradeoffs that materially affected the decision.
- Link conditions, dependencies, actions, implementation records, and any later decision that supersedes the entry.
A practical structure to follow
Use these elements as a decision checklist, not as a rigid formula. The exact wording should still fit the reader, context, and purpose.
- Give each material decision a stable identifier and clear decision statement.
- Record decision date, effective date when different, decision owner or authority, and status such as proposed, approved, superseded, or reversed.
- Summarize the problem or choice and the criteria that mattered.
- Record alternatives considered and the evidence or tradeoffs that materially affected the decision.
- Link conditions, dependencies, actions, implementation records, and any later decision that supersedes the entry.
How to write decision log step by step
- 1Identify which choices are consequential enough to deserve durable documentation.
- 2Write the final decision in one sentence before summarizing discussion.
- 3Confirm who had authority to make or approve the choice.
- 4Record only the alternatives and evidence that actually mattered to the outcome.
- 5Separate assumptions, unresolved risks, and conditions from the decision itself.
- 6When a decision changes, preserve the original record and link the superseding decision rather than silently rewriting history.
8 Decision Log examples
Read the examples for structure and choices rather than copying surface wording. Notice what stays consistent and what changes with audience or purpose.
D-021 — Approve a two-wave migration rather than one global cutover; decision owner: Program Sponsor; rationale: reduces simultaneous support load while preserving the target quarter; condition: configuration must be frozen between waves except through approved change control.
D-022 — Keep weekly steering meetings for the first four weeks after launch, then move to exception-only meetings if open severity-one issues remain at zero.
D-023 — Select Vendor B because it meets the mandatory data-residency requirement and total evaluated cost remains within the approved ceiling; Vendor A is rejected despite lower license price because it does not meet the mandatory criterion.
D-024 — Defer the optional reporting export to a follow-up release so the accepted migration scope is not expanded after final test approval.
Product decision: retain the existing navigation label after the usability test did not show a meaningful comprehension advantage for either proposed replacement.
Policy decision: require manager approval only for exceptions rather than for every standard request; effective after the revised procedure and access rule are deployed.
Decision Log templates
Replace every bracketed field with situation-specific information. A template is a starting structure, not finished copy.
Decision log Decision ID: [x] Status: [proposed/approved/superseded/etc.] Decision: [one sentence] Decision owner/authority: [x] Decision date: [x] Effective date: [x] Context/problem: [x] Criteria: [x] Alternatives considered: [x] Rationale/evidence: [x] Tradeoffs/risks: [x] Conditions: [x] Actions/links: [x] Superseded by: [x]
Lightweight decision record Choice: [x] Why now: [x] Options: [A/B/C] Decision: [x] Why: [two or three decisive reasons] Owner/date: [x] Follow-up: [x]
Decision reversal record Prior decision: [ID/link] What changed: [new evidence/constraint] New decision: [x] Authority/date: [x] Impact on active work: [x] Actions required: [x]
Common mistakes to avoid
- Using the log as meeting minutes and burying the actual decision inside discussion notes.
- Recording only the outcome with no rationale, making later review impossible.
- Calling a recommendation or preference a decision before the authorized person approves it.
- Editing an old decision to match current thinking instead of recording a superseding decision.
- Omitting conditions or assumptions that would materially change whether the decision still holds.
Final revision checklist
- Does the opening make the purpose clear quickly?
- Is every important claim, detail, or example doing a distinct job?
- Could a reader misunderstand any pronoun, transition, time reference, or instruction?
- Is the tone appropriate for the relationship and situation?
- Can you remove repetition without removing necessary context?
- If the writing contains factual claims, names, dates, quotations, or citations, have you verified them independently?
Questions about Decision Log
What is Decision Log?
A decision log is a durable record of material choices made during a project, product, operation, or governance process. It captures what was decided, who had decision authority, when the decision became effective, the context and alternatives considered, the rationale and evidence that mattered, and any conditions or follow-up created by the choice.
What makes Decision Log effective?
A strong decision log prevents teams from repeatedly reconstructing why a choice was made. It distinguishes a final decision from a recommendation or open question, preserves the key rationale without reproducing every discussion, records conditions and superseded decisions, and links follow-up actions or implementation work.
How do I write Decision Log?
Start with the purpose and reader, then work through the structure in order. Draft for meaning first, check the examples for pattern, and do a final revision for clarity, accuracy, tone, and unnecessary repetition.
What should I avoid when writing Decision Log?
Using the log as meeting minutes and burying the actual decision inside discussion notes. Recording only the outcome with no rationale, making later review impossible. Calling a recommendation or preference a decision before the authorized person approves it.
Should Decision Log show one “last updated” date or track verification at the claim level?
Use a page-level revision date for editorial history, but do not let it imply that every statement was reverified on that date. Changeable facts, quotations, policies, project facts, market data, provider capabilities, and other consequential claims should carry a source record with their own last-verified date or version and a specific recheck trigger. Stable editorial synthesis and original instructional examples can use the page revision/version record instead. When a material correction, retraction, or recommendation change affects what the reader should believe or do, retain the prior record and disclose what changed and why.
How do I know whether a claim or source on a Decision Log guide is stale, corrected, or still active?
Do not infer status from the page-wide update date. Check the controlling source or project record, the exact version/date last verified, and the trigger that could make the item changeable. Keep it active when the source still controls the exact claim; mark review due when a trigger has fired but the conclusion is not yet disproved; mark stale when the old version no longer controls; and use corrected, retracted, withdrawn, or superseded when the editorial history requires it. The correction level should match reader impact: cosmetic edits are not the same as a material factual correction or a critical source failure.
If a source behind Decision Log changes, how do I know which other claims or guides need review?
Use the dependency map rather than reviewing the entire site blindly. Identify the exact claim or example that depends on the source, classify the dependency as direct, shared, advisory, or independent, and record why the source changed. Direct dependents should be reviewed immediately when a controlling source is corrected, retracted, superseded, or no longer supports the claim. Shared dependents can be queued by source/claim ID and scope. Replace the source only when the replacement performs the same evidentiary job—or change the claim. Keep the old source/status in the ledger, then propagate the review to templates, examples, and related guides only where that dependency actually exists.
How can editors track a source change for Decision Log without reviewing the entire site?
Use persistent claim, source, and dependency records. Link only the claims that truly depend on a source, then change that source record’s status in the Writing Authority admin when it is corrected, superseded, stale, withdrawn, or retracted. The registry queues the linked claims with a reason code and priority. Reviewers can see the affected guide, inspect the source/dependency IDs, revise or replace the evidence where necessary, and close the queue item after verification. Original site-created examples and templates remain independent unless they contain a real external factual dependency.