THE SHORT VERSION

A decision log is a compact record of commitment: decision, owner, date, reason, effects, and a link to the fuller context.

Meeting notes often mix observations, questions, and commitments into one long stream. Weeks later, a reader may find every comment except the answer they need. A decision log solves a narrower problem: it makes the current commitment easy to find.

The format below is an original team exercise. It does not replace regulated records, formal approvals, contracts, or the documentation required by your organization.

Record a decision only when one exists

Start with a complete sentence: “The project will use the shorter onboarding flow for the September test.” Avoid headings such as “Onboarding” that leave the reader to reconstruct the conclusion.

If the group discussed an idea but did not decide, write it in an open-questions list. Turning a suggestion into a decision by accident can be worse than leaving the meeting undocumented.

Keep six fields

A practical entry can use these fields:

Field Purpose
Decision The commitment in one sentence
Date When the decision became current
Owner Who is responsible for carrying it forward
Reason The constraint or goal that shaped it
Effect The work, audience, or system it changes
Revisit when A date or condition that should reopen it

The reason should be specific enough to explain the choice without recreating the whole debate. “Because it is better” does not help. “Because the test window cannot support both flows” preserves the constraint that mattered.

Link to the meeting record, research, or approved proposal when someone may need the detail. Give the link a descriptive label. A later reader should know whether it points to a draft, evidence, or formal approval.

Do not paste private chat or personal information into a broadly shared log merely because it influenced the conversation. Summarize the operational reason and keep sensitive records in the system with the right access controls.

Make superseded decisions visible

Do not silently rewrite an old entry when the team changes direction. Add a new decision and mark the older one as superseded with a link to its replacement. This preserves the history without asking the reader to compare document versions.

For example, a fictional September decision might replace an August decision after a vendor changes a deadline. The new entry should state that trigger. It should not make the previous decision look careless when it was reasonable under the information available then.

Review by condition, not ritual

Some decisions need a scheduled review. Others should reopen only if a condition changes, such as a budget, policy, or dependency. Writing that condition reduces repetitive discussion and helps the team notice when an old assumption no longer holds.

During a handoff, link the relevant decision rather than claiming that “everyone agreed” without evidence. The log supports a shared understanding; it is not a substitute for communicating changes to people affected by them.

A final editing pass

Read the entry as someone who missed the meeting. Can that person identify what is true now and who acts next? Remove commentary that does not change either answer. A good decision log is shorter than the discussion because it has a different job.

Questions about this article? Contact the publication.

Editorial policy