Decision Log (2026): Template, Examples, and How to Keep One Without Anyone Filling It In
Guide · September 2026 · 6 min read
TL;DR
A decision log is a running record of the decisions a team or company makes: what was decided, who decided it, when, the alternatives considered, and the reasoning. It is the cheapest fix for the most expensive question in any organization, which is why did we do this, asked six months later by someone who was not in the room. The template below has eight fields and takes two minutes per entry. The problem is that nobody makes the entry, because decisions happen in Slack threads, meetings and hallway conversations, and the log lives somewhere else. Sentra solves that by reading those channels and keeping the decision log itself: every decision, its author, its date and any later reversal, queryable by people and AI agents. The template, three worked examples, the difference from a decision register and an architecture decision record, and the ways to keep the log current are all below.
What is a decision log?
A decision log is a chronological record of decisions with enough context that someone reading it later understands not just what was chosen but why. It is different from meeting notes, which record everything said, and from a project plan, which records what will be done. The decision log records the moments where the plan changed and the reasons it changed.
Three related terms get used interchangeably and should not be:
- Decision log. The chronological record, usually one row per decision, kept by a team, a project or a company. Optimized for answering "what did we decide about X and when."
- Decision register. The same content organized as a register with status fields (proposed, approved, superseded), usually owned by a PMO or governance function. Optimized for tracking open decisions to closure.
- Architecture decision record (ADR). One document per significant engineering decision, stored in the code repository next to the code it affects, with a fixed structure of context, decision, consequences. Optimized for engineers reading history in the repo.
Most companies need the first, some need the second, and engineering teams benefit from the third. All three fail the same way, which the next sections cover.
The decision log template
Eight fields. Anything more and people stop filling it in; anything less and the entry is useless a year later.
| Field | What to write | Example |
|---|---|---|
| Date | When the decision was made, not when it was logged | 2026-09-14 |
| Decision | One sentence, in the past tense, stating what was chosen | Moved the Atlas V3 launch from 12 October to 2 December |
| Owner | The person accountable for the decision, one name | Head of Product |
| Context | The situation that forced a decision, two or three sentences | Payments integration slipped three weeks; marketing had committed the October date to two partners |
| Alternatives considered | What else was on the table and why it lost | Ship without payments (rejected: partner demo needs it); partial launch to existing customers (rejected: support load) |
| Reasoning | Why this option won | A December date protects the partner demos and lands before the holiday freeze |
| Who was informed | Teams or people who need to act on it | Marketing, Sales, Partnerships, the two named partners |
| Status | Active, superseded, or reversed, with a link to the later decision | Active |
Copy the table into Notion, Confluence, a spreadsheet or a Markdown file. The format matters less than the eight fields.
Decision log examples
- Launch date change. Decision: moved the launch from October to December. Owner: Head of Product. Reasoning: payments integration slipped and partner demos need it. Status: active. The value of this entry shows up when someone in January asks why the launch was late and finds the payments slip instead of guessing.
- Vendor selection. Decision: chose HubSpot over Salesforce for the sales team. Owner: VP Sales. Alternatives: Salesforce (rejected on implementation time and cost), Pipedrive (rejected on reporting). Reasoning: live in three weeks with native marketing automation. Status: active. Two years later, when someone proposes switching, this entry tells them what was already weighed.
- Pricing change, later reversed. Decision on 3 March: introduced a per-seat tier at 50 dollars. Decision on 21 May: reversed, moved to usage-based tiers after enterprise buyers pushed back on seat counts. The second entry links to the first and marks it superseded. Without the link, both prices circulate as current, which is the exact failure a decision log exists to prevent.
Why decision logs go stale in six weeks
Decision logs die for one reason: the decision and the log happen in different places. Decisions are made in a Slack thread at 6 pm, in the last four minutes of a meeting, or in a one-to-one that nobody minutes. The log is a page somewhere that someone has to remember to open afterwards.
A staff AI engineer at a sports-data company described the pattern to us exactly: people make a decision or change the workflow, communicate it verbally to their stakeholder, nobody updates the documentation, and a new joiner later picks up a feature that was already done. The knowledge was decided; it was never recorded. A chief of staff at a healthcare company told us their requirement in three words, commitment tracking and briefs, because the decisions were being made faster than any human could log them.
Templates and process do not fix this, because they add a step to the person who already has the least time. The fix is to take the writing step away from the human.
How to keep a decision log without anyone filling it in
| Approach | Who writes the entry | Captures decisions made in Slack and meetings | Tracks reversals and supersession | People and AI agents can query it |
|---|---|---|---|---|
| Sentra | Sentra, automatically, from the source channel | Yes, reads Slack, email, meetings, tickets and documents | Yes, every decision is a time-stamped fact with history | Yes, in Slack, in the app, and over REST and MCP |
| Notion or Confluence template | A person, after the fact | No | Manually, if someone remembers to link the entries | As a page or database |
| ADRs in the repository | The engineer proposing the change | No, engineering decisions only | Yes, by convention, with a superseded status | As Markdown in git |
| Jira or Linear | A person, as a ticket or comment | Partly, if the decision is made in the ticket | No | As tickets |
| Spreadsheet | A person, after the fact | No | Manually | Only people |
Sentra treats a decision as a fact with a date and an author, the same way it treats a commitment, a deadline or a price. When someone in a Slack channel writes that the launch is moving to December, or a meeting ends with an agreement on a vendor, Sentra records the decision, who made it, when, and which earlier decision it replaces. The decision log is then a question rather than a page: ask what was decided about the launch date and the answer comes back with the whole history, in Slack, in the Sentra app, or to any AI agent over MCP. Permissions follow the source, so a decision made in a private channel stays visible only to the people who could see that channel.
This is the difference between a decision log that exists and one that is trusted. At Lenskart, 153 leaders across ten departments ran roughly 11,000 queries a week against that record within four weeks, and cross-department work got 58 percent faster, largely because the question "what did we decide" stopped requiring a meeting.
How to choose
- Decisions are made across Slack, meetings and email, and you want the log kept for you and readable by agents: Sentra.
- You want a lightweight manual log for a single project with a disciplined owner: the eight-field template in Notion or Confluence.
- You are recording engineering architecture decisions for engineers: ADRs in the repository, plus Sentra if the product and business decisions around them need to connect.
- You need governance status tracking on open decisions: a decision register, fed from the log rather than maintained separately.
Frequently Asked Questions
What should a decision log include?
Date, the decision in one sentence, the owner, the context, the alternatives considered, the reasoning, who was informed, and the status. Eight fields is the most a busy team will maintain by hand.
What is the difference between a decision log and a decision register?
A decision log is a chronological record of decisions made. A decision register adds governance fields such as proposed, approved and superseded, and tracks decisions to closure. The register is usually derived from the log.
What is an architecture decision record?
An ADR is a single document recording one significant engineering decision, with its context, the decision and its consequences, kept in the code repository. It is a decision log format specialised for engineers.
How do you keep a decision log up to date?
Either assign an owner and accept that entries lag the decisions by days or weeks, or use a system such as Sentra that reads the channels where decisions happen and records them automatically with their date and author.
Can AI agents use a decision log?
Yes, and it is one of the highest-value things an agent can read, because it explains why the current state exists. Sentra exposes decisions as time-stamped facts over REST and MCP so agents built on Claude, ChatGPT, Gemini or custom frameworks can check what was decided before they act.
Which Sentra is this?
Sentra at sentra.app is the company brain, an organizational memory layer for teams and AI agents. It is unrelated to Sentra.io, the data security company.