A project can have excellent meeting minutes and still lose the reason behind an important choice. Minutes describe a conversation. A decision log preserves a particular commitment: what was chosen, which alternatives were considered, what the choice depends on, and when it should be reconsidered. That makes it useful after the people in the room have moved to another task.
Use one short entry per decision rather than a running paragraph that mixes several choices. The example in this guide is fictional: a small publishing team must choose whether to send a draft guide as a PDF or as editable text. The point is the structure of the record, not a recommendation that one format is always better.
Start with the question and its boundary
“Choose an export format” is too broad. “Choose the review format for the first draft of the October guide” identifies a specific decision. State what is outside the entry as well. This decision does not determine the permanent archive format or the format for the final public page.
A clear boundary prevents later readers from treating a local choice as a universal policy. Add a date, a stable identifier such as DEC-07, and the person responsible for confirming the decision. If your team has a formal approval process, the note should point to that process. Writing a name in a note does not create approval.
List genuine alternatives
Record the options that were actually available. For the fictional example, those are a PDF for fixed-layout comments, editable text for suggested wording, and a linked draft page for browser review. Include a brief reason an option was rejected, especially when it would otherwise look obvious to a future reader.
Avoid inventing a comparison merely to make the entry look thorough. If only one viable option was known, say that and identify the constraint. “Only PDF export was available before the review deadline” is more informative than a table containing alternatives nobody could have used.
Connect evidence to the choice
Evidence should explain the tradeoff. In the fictional scenario, the reviewers need to propose wording changes, the draft contains no complex layout, and a final copy is due the next morning. Those conditions support an editable review copy. They do not establish that editable text is the best format for every review.
Separate a measured observation from a preference. “Reviewer requested editable paragraphs” is a reported requirement. “The PDF is easier to read” is an opinion unless you identify whose opinion it is and why it matters. Link to the relevant brief or source note if the decision depends on details kept elsewhere.
A copyable decision entry
Decision ID: DEC-07
Question: What format should the first guide draft use for review?
Scope: First wording review only; final publication is separate.
Choice: Editable text with numbered section headings.
Alternatives: PDF; linked draft page.
Reason: Reviewers need line-level wording changes by tomorrow.
Constraint: No layout approval is included in this review.
Owner: Publishing coordinator.
Confirmation: Link to the team's recorded approval.
Revisit if: A layout review becomes necessary before publication.
Next action: Send one clearly named review copy.
This entry is intentionally small. Add a source link or an exception when it changes the decision, rather than filling every record with a complete history of the project. The log should remain easy to scan when someone asks why the current approach exists.
Make the revisit trigger observable
“Review later” rarely helps. A useful trigger names a change that a person can notice: a new layout requirement, a missed deadline, a reviewer who cannot open the file, or a change in the audience. You can also include a review date when the choice has a known shelf life.
Do not confuse a trigger with a promise to reverse the decision. When the trigger occurs, reassess the evidence and options. The original choice might still be appropriate. A separate field for “review outcome” lets you record that assessment without pretending the initial reasoning never happened.
Record superseding decisions
If the team later moves to a PDF for final layout approval, create a new entry and mark DEC-07 as superseded for that stage. Link the two entries. Keep the original scope visible so readers can see that the first decision was valid for a different task.
Avoid changing the old choice in place without a note. That makes an earlier action appear inconsistent with a record that has been quietly rewritten. A simple sequence of dated entries preserves the explanation while allowing the project to change direction.
Use the log during a handover
Before handing work to someone else, select decisions that still constrain their next action. They probably need the current format, the reason for it, and the condition that would justify changing it. They may not need every abandoned draft or conversational detail.
A decision log does not replace a task list. “Send the review copy” belongs in the work system with an owner and due date; the decision entry explains why that copy uses its current format. Keep those links connected, and the record becomes a practical aid to continuity rather than a second place to maintain the same tasks.
Use the BiNotePads online notepad to adapt this example. For a separate copy of important work, follow the browser-note backup guide.