A decision log is a one-page index of the decisions a team has made. It is not a replacement for individual decision records — those still exist, with full context, in their own files. The log is the table of contents. When someone asks "did we decide on retry behavior?" the log is what you check before asking the team. Every team that has gone through the pain of a re-decided architecture choice has eventually built one.
The template below is the lean version. The log is meant to be skimmable; if it is more than fifty rows long, you need pagination, not more columns. The discipline is to keep each row to one line that is searchable. The richer document lives behind the link.
When to use it
- Your team has written more than ten decision records and they are getting hard to find.
- You hear "didn't we already decide this?" more than once a quarter.
- New hires need a way to scan past decisions without reading every record.
- You want a quick artifact to bring to the quarterly decision review.
The template structure
This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.
DECISION LOG — [team name] Last entry: [date] Owner: [name] ID | DATE | DECISION (one line) | DECIDER | STATUS | LINK ------+------------+------------------------------------+---------+-----------+------ DEC-1 | 2026-01-08 | Move retry logic to gateway layer | A. Patel| superseded| [link] DEC-2 | 2026-01-15 | Adopt feature-flag service Z | M. Tran | active | [link] DEC-3 | 2026-01-22 | Drop support for legacy webhook v1| A. Patel| active | [link] DEC-4 | 2026-02-04 | Replace cron with scheduled funcs | T. Liu | active | [link] DEC-5 | 2026-02-11 | Move to 1-week sprints | A. Patel| reversed | [link] DEC-6 | 2026-02-19 | Two reviewers for billing changes | M. Tran | active | [link] DEC-7 | 2026-03-03 | Adopt dependency scanner Q | T. Liu | active | [link] DEC-8 | 2026-03-15 | Standardize ADR template | A. Patel| active | [link] LEGEND active — currently in effect superseded — replaced by a newer decision (link to it) reversed — the team backed out; see record for why proposed — under review, deadline in record deferred — explicitly postponed; trigger in record WHEN TO ADD A ROW - Every accepted decision record gets a row. - When a decision is superseded, update the old row's status and add a new row for the new one. - When a decision is reversed, update the row, do not delete it. HOW TO SEARCH Ctrl-F by topic. If you cannot find a decision you remember, the problem is the wording of the row, not the absence of the record.
Governance, not a status channel
StandIn is async governance infrastructure. Engineers declare working state before they go offline. Representatives answer from the record, cite the source, and refuse when the answer is not there.
Request access →How to use it well
- One line per row, full stop. The log is for skimming. If a decision needs two lines, the verb in the row is wrong. Use the linked record for nuance.
- Status is the load-bearing field. "Active" and "superseded" let a reader know whether a row is current. Without that field, the log degrades into a list of every opinion the team has ever recorded.
- Never delete a row. Reversed decisions stay in the log with the reversed status. Deleting them creates the same problem decision logs are meant to solve — the team forgets it considered something.
- Number sequentially. A serial ID lets people refer to a decision in conversation without ambiguity. Sequential numbering also makes it obvious how many decisions are being recorded — and how few, in teams that need to record more.
- Bring it to the quarterly decision review. The log is the input to the inventory step of the review.
What to skip
Skip adding more columns. A "category" column or a "tags" column sounds useful and is dead weight in practice. The log is short; the linked record is where richer metadata lives. Every additional column makes the log harder to skim and easier to abandon.
Skip backfilling the log with decisions from before you started keeping it. Past decisions that were not recorded at the time can be re-decided when they next come up. Time spent doing archaeology on a year of Slack history is time not spent on the current quarter's decisions.
Frequently asked questions
Is this template free?
Yes. The table above is the log. Use it as a Notion table, a Markdown table, or a spreadsheet — whichever your team will actually keep open.
Can I edit it?
Yes, but resist the urge to add columns. Most edits should be to the legend (what statuses you use) rather than the structure.
Do I need to give my email?
No. The download is a formatted version; the email is just for our newsletter.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.