These names are working conventions, not universal standards. Some teams call a detailed record a decision log. Agree on what each record must contain before choosing a tool or moving existing notes.
Decide what the record needs to answer
If a colleague needs to know who decided something and whether it still applies, start with a log. If they need to understand why an option won, keep a journal entry behind the log row. A routine, easily reversed choice may need only a brief reason. A consequential or contested choice deserves enough context to review.
| Reader's question | Decision log | Decision journal |
|---|---|---|
| What did we choose? | One sentence and a stable ID | The choice in its original context |
| Who owns it? | Named owner and decision date | Owner, contributors and unresolved disagreement |
| Does it still apply? | Current status and replacement link | Dated review notes explaining any change |
| Why this option? | Brief reason plus a record link | Alternatives, evidence, assumptions and tradeoffs |
| When do we look again? | Review date or trigger | What observation would change the choice |
This distinction is a suggested workflow. It does not mean every team needs two documents for every decision. A single document with an index and linked entries can serve both purposes.
Copy this decision log template
Use one row per decision. Give each row an ID that stays the same when its status changes. Keep the detailed evidence in a permitted record rather than squeezing private material into a widely shared spreadsheet.
ID | Decision date | Question | Decision | Owner | Status
Brief reason | Reasoning record | Review date or trigger | Replaced by
Suggested statuses: Proposed / Accepted / Superseded / ClosedUse “Proposed” until the person with authority has agreed. Use “Superseded” when a later decision replaces this one, with a link to that replacement. Define “Closed” for your team—for example, a completed temporary decision—so it does not become a vague label for something nobody has reviewed.
An action list answers a different question: who will do what by when. Link the next task to its decision ID, but keep task completion separate from decision status. Completing an evaluation does not automatically approve a purchase.
One choice, two useful views
Fictional example: a small software team is considering whether to evaluate an assistant that drafts support replies. The following dates and constraints are invented to show the format; they are not Feedsion customer results.
| Field | Log row |
|---|---|
| ID and date | D-014 · October 13, 2026 |
| Question | Should we start a limited support-drafting evaluation? |
| Decision | Evaluate on permitted, redacted examples with human review |
| Owner and status | Maya · Accepted |
| Brief reason | Check usefulness before making an integration commitment |
| Reasoning record | D-014 journal entry, accessible to the evaluation team |
| Review trigger | October 27, or earlier if permission or access changes |
| Replaced by | None |
The linked journal entry would explain the alternatives: continue the current process, run a limited evaluation, or integrate now. It would distinguish a demonstration from evidence gathered on the team's own permitted examples. It would record unresolved questions about factual accuracy and review effort, plus the agreed limits: no automatic sending and no unapproved customer data.
The log makes the accepted scope easy to find. The journal makes it possible to understand that scope without reconstructing a meeting from memory. For a full entry structure, use the decision journal template.
Upgrade an old log without inventing its history
Start with decisions that still affect current work. Preserve the original row and date. Add a new, dated explanation that separates the original record from what you can establish today.
For example: “Reason not recorded on October 13. On October 20, Maya recalled that review effort was the main concern; no contemporaneous note was found.” That is a later recollection, not original evidence. Link any surviving source and identify uncertainty rather than filling the gap with a plausible story.
When a choice changes, add a successor record and point the old row to it. Michael Nygard's architecture decision record approach similarly retains superseded decisions and their replacements. It is an engineering-specific reference, rather than a required format for every business decision. Read Nygard's original explanation.
Keep the log usable as the team grows
Choose one place where authorized colleagues can find accepted decisions. Check that a link works for its intended reader; a public index must not expose private journal contents. A spreadsheet is enough to try this structure. You can use it without a particular product or automatic synchronization.
At your weekly decision review, look for entries whose review trigger has arrived, links that no longer work, and choices that have been replaced without updating the index. Append what changed and why. Keep the original reasoning available for comparison.
Common questions
Can a decision log replace meeting minutes? It can summarize decisions made in a meeting, but minutes may also record discussion and other required details. Link the source where appropriate; do not treat the log as proof of agreement when authority or approval remains unresolved.
Does every log row need a journal entry? No. Use the shortest record that preserves the reasoning needed for a later review. Expand entries when the consequences, uncertainty or disagreement warrant it.
What belongs in the first row? Pick one current decision that someone else will need to understand. Record its owner, accepted scope and next review trigger, then add a reasoning link if the row alone would leave a material question open.