Decision log
A decision log is a running, dated record of the calls that constrain future work: what was decided, why, what was rejected, and who owns it.
A decision log is a running, dated record of the calls a team has made that later work must respect. Each entry answers four questions: what was decided, why, what was rejected, and who owns the call. It is append-only: when a decision changes, you add a new entry that supersedes the old one instead of editing history.
An example entry
## 2026-10-14: Guest checkout skips the login code before payment
Decision: Guest checkout never asks for a one-time login code before payment.
Why: Login-code friction cost conversion in the September test.
Rejected: Code before payment (fraud team's preference); magic link at checkout.
Owner: Priya (PM, Checkout). Agreed: Checkout eng, Fraud.
Source: #checkout thread, 14 Oct. Review: 2027-01-15.
One sentence of verdict, one of reason, the options that lost, a named owner, and a link back to where it was decided. If it takes longer than a minute to write, the format is too heavy and entries will stop. Our decision log template has copy-ready versions.
Decision log vs ADR vs meeting notes vs decision register
- Decision log: every decision that constrains future work, product or engineering, in one chronological list.
- ADR: one file per architectural decision, kept in the repo next to the code. An ADR folder is a decision log scoped to architecture.
- Meeting notes: the discussion. Decisions get buried in them, which is why they make a poor log.
- Decision register: a structured table of decisions with more fields (stakeholders, status, follow-up tasks, review date). A log is the stream; a register is the database view of it.
How to keep one alive
Decision logs rarely fail for lack of a template. They fail because filing is a manual step at the moment the decision already feels handled, so entries stop, or because nobody reads them, so decisions get relitigated anyway.
- Make the decider own the entry. Not "the team"; the one person who made the call.
- Capture at the moment of decision, not in a weekly cleanup.
- Filter hard. Log only calls that will constrain how someone builds or plans later.
- Supersede, never edit. History is the value.
- Deliver it. Link the entry wherever the decision comes up, and brief new engineers and AI coding agents from it.
Lockstep automates the filing and delivery: it drafts entries from Slack, Notion, and Jira, the owner approves each with one click, and approved decisions brief engineers and AI agents. For how engineering teams run one, see the engineering decision log guide; to compare tools, see best decision log software.
- What is a decision log?
- A running, dated list of the decisions that constrain future work. Each entry records the verdict in one sentence, the reason, the alternatives rejected, who decided, and when. It is append-only: a reversed decision gets a new entry pointing at the old one.
- Which tools do product teams use for a decision log?
- Most start with a Notion database or a Confluence page, some keep ADR files in the repo, and some use a tool that captures decisions automatically, such as Lockstep, which drafts entries from Slack, Notion, and Jira for one-click approval by the owner.
- How is a decision log different from meeting notes?
- Meeting notes record the discussion; a decision log records only the outcome. A reader six weeks later should get the verdict and the reason in thirty seconds, without reconstructing it from a narrative of who said what.
Related