A decision log records what was chosen, why it was chosen, and what would justify revisiting it. Meeting notes tell the story of a discussion; the log gives a reader a short route to the current choice and its supporting context.
To build one, take a single confirmed choice from your meeting notes, record the alternatives and reasons, add a source reference, and name the person who will keep the entry current. If the discussion did not reach a decision, say so. A neat entry should not turn a proposal into an agreement.
Keep decisions separate from tasks
“Use a written update before the weekly call” is a decision about how the team will work. “Send the update outline on Thursday” is a task that may follow from it. Completing the task does not prove the decision was a good one, and changing the decision does not automatically cancel every related task.
Keep the two records connected without making them identical. Use a decision ID in the task when that connection matters. Our meeting action-item guide covers the separate job of specifying work, owners, and timing.
Choose what is worth an entry
Start with choices that someone is likely to question or need to understand later: a recurring workflow, an agreed project scope, or an option selected over a plausible alternative. You do not need a formal record for every small conversational preference.
Try this test: “Could a teammate reasonably ask why we do it this way?” If the answer depends on a discussion that is otherwise hard to find, a short entry may be useful.
Software teams use a related practice called an architectural decision record. AWS describes these records as preserving a technical choice with its context and consequences. The template here adapts that general idea for everyday project meetings; it is not an AWS standard for nontechnical teams.
Copy this eight-field decision log template
Use one entry per choice. A plain document is enough; the fields can also become columns if your team prefers a spreadsheet.
- Reference and question: Give the entry a stable ID and state the question the team needed to answer.
- Status and date: Mark it as proposed, agreed, deferred, rejected, or superseded. Record the relevant date, not just the document's last edit date.
- Choice and scope: State exactly what was selected, where it applies, and any conditions or time limit.
- Context and alternatives: Explain the problem and list the options actually considered. Do not invent a comparison after the fact.
- Reason and trade-off: Explain why the selected option fit the situation, including the disadvantage the team accepted.
- Source and confirmation: Link the relevant notes, passage, or accessible recording moment. Record who confirmed the choice and when; the note writer is not automatically the decision maker.
- Record owner and follow-up: Name who maintains this entry and link any separate tasks. Keep missing ownership visibly unconfirmed.
- Revisit trigger and history: State the agreed review point, if any, and link later corrections or replacement decisions.
The AWS guidance on record contents also emphasizes alternatives, trade-offs, status, and change history. Our added question, source, and follow-up prompts are intended to make the record usable alongside ordinary meeting notes.
Worked example: changing the weekly project update
This example is fictional. It is not a Recolx customer story, an internal company record, or output from a Recolx product.
Imagine a project team discussing whether to replace its weekly 45-minute update call. The group considers a written update alone, the current call, and a written update followed by a 15-minute question session. It agrees to try the third option for four weekly updates, then review it.
A rushed note says: “We are stopping weekly meetings because written updates are better.” That loses both the question session and the limited trial. It also presents an expected benefit as an established result.
A more useful entry would read:
- Reference and question: D-014 — How will this project team share weekly progress?
- Status and date: Agreed in the fictional project meeting; enter the actual meeting date when using this format.
- Choice and scope: Try a written update plus a 15-minute question session for this team's next four weekly updates. This does not change other teams' meetings.
- Context and alternatives: Routine progress was being read aloud in the existing call. The team considered keeping that call, using written updates only, or retaining a shorter question session.
- Reason and trade-off: The chosen option keeps an opportunity for questions while moving the routine update into writing. It also requires preparation before the session. Whether it works better remains to be checked.
- Source and confirmation: The agreement described in this fictional example. In a real entry, link the actual passage and record the confirmation; do not copy this placeholder as evidence.
- Record owner and follow-up: Morgan, the fictional note owner, maintains the entry. The update-outline task is tracked separately.
- Revisit trigger and history: Review after the fourth update. No replacement decision has yet been made.
The record explains a choice without claiming a measured improvement. It also gives a new teammate enough information to avoid treating a temporary trial as a permanent rule.
Check the entry before calling it agreed
Read the relevant part of the meeting notes, not just the proposed log entry. Check three things:
- Was a choice actually made? “Let's think about it” is not an agreement.
- Does the scope match? Preserve limits such as one team, four updates, or only after a prerequisite.
- Is the reason supported? Separate the reason stated during the discussion from your later interpretation.
If something is missing, mark it as unconfirmed and ask the relevant participants. Do not fill an empty field with a plausible answer. A recording can be a reference when one is available for you to use, but this workflow does not require recording the meeting.
Show what changed without erasing the earlier reason
Distinguish a correction from a new decision. Fixing a misspelled project name is a correction; choosing a different update format after the trial is a new choice.
For a replacement choice, create a new entry and connect both records. Mark the earlier one as superseded and identify the replacement. For a meaningful correction, keep a brief note of what was corrected and why. Avoid silently replacing the earlier reasoning with what the team knows now.
AWS's ADR process similarly preserves accepted decisions and links the later record that replaces them. You can adapt that principle without adopting a complex approval workflow.
Store the log where the team already keeps its meeting records. Our meeting knowledge-base guide explains the broader organization and retrieval system; this page focuses on the contents of an individual decision entry.
Common questions
What if no reason was recorded?
Write “reason not recorded” and ask for clarification. If someone supplies a reason later, date that explanation so it is not mistaken for a note made during the meeting.
Can a decision log include unresolved choices?
Yes. Keep proposed and deferred entries clearly labeled. Their presence in the log must not make them appear agreed.
Does the record owner have authority to change the decision?
Not necessarily. Maintaining the document and making the choice are different responsibilities. Follow the team's actual decision process and record who confirmed any replacement.
Start with one choice from your next meeting
Copy the eight fields, choose one discussion worth preserving, and check the entry with the people involved. The useful outcome is a clear answer to “What did we choose, why, and does it still apply?”
If you are also exploring capture tools, visit the current Recolx Tap product page. This decision-log method works with ordinary written notes and does not depend on a particular device.
