Decision Log Template: Record Who Decided What, and Why

A decision log template needs seven fields per entry: the decision in one line, the date it was made, the decider (a named person, always), the options considered, why this one won, its status, and which earlier decision it supersedes, if any. Give each entry a number that is never reused, keep one log per project in one place, and never edit a decided entry to change it: write a new one that supersedes it. The template, filled examples and the rules that keep the log findable are below.

This page is about recording decisions once they are made. How to make them, including who gets a say and how disagreement ends, is covered in decision-making frameworks for small teams.

Why keep a decision log

Three months after a decision, someone new asks why the team does it this way. Without a record, Michael Nygard wrote in the 2011 post that popularized architecture decision records↗ (opens in a new tab), that person has two choices: blindly accept the decision, or blindly change it. Accepting may be fine if the reasons still hold. Changing it without knowing why it was made can quietly break the thing it was protecting. A log gives the third choice: read why, then decide whether the reason still stands.

It also ends repeat arguments. When the question comes back, the answer is “DEC-014, decided June 3 by Sam, because of the contract terms,” not another meeting. And it shows what is still open, which is often more useful than what is settled.

The fields

• Number: DEC-001, DEC-002, in order, never reused, even when an entry is withdrawn. A number quoted in an email a year from now must still point to the same decision.
• Decision: one line in plain words, written so someone skimming the log understands it. “Launch in the US only; Canada after the first 100 customers.”
• Date: the day it was decided, which may be earlier than the day it was written down.
• Decider: a named person, or several named people. A group can discuss, but the log names who made the call. An AI assistant can draft an entry; it is never the decider.
• Options considered: what else was on the table, and in a few words why not. This is the field people skip and later wish they had.
• Why: the reason that would convince someone who was not in the room. Include the constraint that forced it, such as a deadline, a contract or a budget.
• Status: open (waiting for someone to decide), proposed, decided, superseded, reversed or withdrawn.
• Supersedes: the number of the entry this one replaces. The old entry stays, marked superseded, with a pointer forward.

Optional fields earn their place on bigger projects: a review-by date for decisions made on thin evidence, the area it applies to (product, technical, legal), and links to the tasks or documents it affects.

What goes in the log, and what does not

A log that records everything is as hard to use as one that records nothing. A useful test: would someone later reasonably ask why? If yes, it goes in.

• In: choices that are expensive to reverse, that other people will build on, that settle a disagreement, or that a customer, auditor or new hire might question. Also standing policies, such as “no deploys after 3 p.m. on Fridays.”
• In: questions that are waiting for a decision, marked open, with the person who will decide.
• Out: routine work choices that one person makes and can undo in minutes, such as which bug to pick up next. The task board already shows those.
• Out: discussion. The log records the outcome and the reason; the debate that led there belongs in meeting notes or a linked document.

A decision log template you can copy

# Decision log: [project]

| No.     | Decision (one line)      | Date       | Decider    | Status     | Supersedes |
|---------|--------------------------|------------|------------|------------|------------|
| DEC-001 | [what was decided]       | [Mon d, y] | [name]     | decided    |            |
| DEC-002 | [question still waiting] |            | [who will] | open       |            |
| DEC-003 | [what was decided]       | [Mon d, y] | [name]     | decided    | DEC-001    |

## DEC-[number]: [decision, in one line]

Status:      [open / proposed / decided / superseded / reversed / withdrawn]
Decided on:  [Month day, year]
Decider:     [name, role]
Supersedes:  [DEC-number, or none]
Review by:   [Month day, year, or "only if X changes"]

Context:     [what made this come up; the constraint that mattered]
Options considered:
  - [option]: [why not]
  - [option]: [why not]
Decided:     [what was decided, in one or two sentences]
Why:         [the reason someone who was not there would accept]
Affects:     [tasks, documents, teams]

Filled examples

## DEC-007: Store all timestamps in UTC; show local time in the UI
Status: decided     Decided on: May 12, 2026
Decider: Ana Ruiz, tech lead
Options considered:
  - Store in each customer's time zone: breaks reports across zones
  - Store server-local time: breaks on daylight saving changes
Why: One rule for every table; conversion happens once, at display.

## DEC-011: Support Safari from version 17 onward
Status: superseded by DEC-019     Decided on: June 2, 2026
Decider: Marcus Lee, product owner
Why: Analytics showed under 1% of sessions on older versions.

## DEC-019: Support the current and previous major Safari only
Status: decided     Decided on: September 22, 2026
Decider: Marcus Lee, product owner
Supersedes: DEC-011
Why: A fixed version number went stale; "current and previous"
     stays true without edits. Review by: March 1, 2027.

Notice that DEC-011 was not edited when the team changed its mind. It stays in the log, marked superseded, so anyone who reads an old ticket citing it can follow the chain to what holds now.

Decision log vs architecture decision records

An architecture decision record (ADR) is one document per significant technical decision, usually kept in the code repository. Nygard’s format has five parts: title, context, decision, status and consequences, and he suggests each be one or two pages, numbered sequentially and never reused, with a reversed decision kept and marked superseded. The ADR GitHub organization’s site↗ (opens in a new tab) defines the relationship plainly: the collection of ADRs created and maintained in a project constitutes its decision log.

So the difference is scope and weight, not kind. ADRs cover architecturally significant choices, such as structure, dependencies and interfaces, with room for the full reasoning. A project decision log also covers product, commercial and operational calls, like a launch market or a support policy, at a line or a paragraph each. AWS’s prescriptive guidance on ADRs↗ (opens in a new tab) describes the same lifecycle both need: a record is proposed, reviewed, then accepted or rejected; once accepted it becomes immutable, and a new insight means a new record that supersedes it. Many teams keep both: ADRs in the repository for engineers, and a decision log that lists every decision, including the ADRs by number.

Keeping it findable

• One log per project, in one known place. Microsoft’s Azure Well-Architected guidance↗ (opens in a new tab) calls its decision record an append-only log that should be readily available, and warns that a decision made but never recorded will likely be forgotten.
• Write the one-line decision for someone skimming. The index is read far more often than the entries.
• Link both ways. Tasks, pull requests and meeting notes cite the decision number; the entry lists what it affects.
• Record open questions too, with who will decide and by when. A list of what is waiting on someone is a working agenda.
• Record decisions from meetings the same day. The meeting minutes template has a decisions section; copy each one into the log with its number.
• Review the entries with a review-by date when that date arrives, and supersede rather than edit.

The decision log in fenbs: Decisions and rules

fenbs keeps this log on the Decisions and rules page, separate from task notes. Each decision gets its own ref, DEC-001 onward, never reused. The entry holds the decision in one line, where it stands (open, proposed, decided, superseded, reversed or withdrawn), the context, what was decided, why, the options considered, who decided, the day they decided, an optional review-by date, a type, the project, and the decision it replaces. When a replacing decision is decided, the old one is marked Superseded, and every change keeps the version before it.

The decider is always a person: a board member, or someone outside the board named with their role. An AI assistant can write a decision down for the person it works for, or add an open question and ask, but it never decides. A decision marked as a rule holds from now on, not just this once, and every connected AI assistant reads the rules first, in full, before its context notes and before it touches a task. Tasks link the decisions they depend on, and a card shows “decision waiting” while one is still open. The whole list downloads as CSV, and a single decision prints or saves as a PDF.

Record this as a rule on the Decisions and rules page, with me
as the decider and my words quoted: "Never ship a pricing change
without legal review." Link it to the open pricing tasks.