14 August 2026
A decision log is a running list of decisions with their reasoning, kept apart from meeting notes and never deleted. Notes describe a meeting; a decision log describes a choice — what was decided, why, what else was on the table, and who owns it. You keep one by capturing each entry the moment the decision is made, not by summarizing the meeting afterward.
Meeting notes are useful for about a week. They tell you what was discussed, who talked, what the mood was — context that matters while the meeting is fresh and stops mattering once the work moves on. A decision, by contrast, keeps mattering for as long as it's in effect. Someone joining the project in month four doesn't need to know that the discussion ran long or that two people disagreed about tone. They need to know that the team chose Postgres over DynamoDB, and why, so they don't reopen a settled argument or repeat a mistake someone already ruled out.
This is the actual case for a separate log: notes are organized by meeting, decisions need to be organized by decision. If your only record is a folder of weekly meeting notes, finding out why a choice was made means searching several documents and reconstructing the thread yourself. A decision log is organized the other way — one entry per decision, each one complete on its own, regardless of which meeting it came from.
A decision log entry is short — usually four to six lines — and it fails if it turns into a transcript excerpt. The fields that make an entry actually useful later are not the ones people default to writing.
The decision itself is the least useful part of the entry. Anyone can infer what was decided from what the team is currently doing — the code, the pricing page, the org chart all show that. What they can't infer is why, and that's the part that actually prevents wasted work. Teams don't usually repeat a decision because they forgot what was chosen; they repeat it because they forgot why it was chosen, and a new person or a new set of pressures makes the old choice look like an oversight rather than a considered trade-off.
This is also why alternatives matter more than most logs bother to record. "We considered X and rejected it because Y" tells a future reader that the option was evaluated, not overlooked. Without that line, every rejected alternative looks like an open question, and someone eventually spends a week reinvestigating something that was already settled — sometimes reaching the same conclusion, sometimes not noticing that the conditions which ruled it out have since changed.
Decision logs die when they depend on someone remembering, after the meeting, to write one. The fix is to make the log the byproduct of the meeting rather than a follow-up task. In practice that means capturing the entry in the room, in the moment the decision is made — not from a transcript reread later, when the reasoning has already gone soft in everyone's memory.
Ownership matters more than tooling. A decision log survives if one person — often whoever runs the meeting, not necessarily the most senior person in it — has explicit responsibility for logging decisions as they happen, even a rough version, with a norm that anyone can correct or add to the entry afterward. It fails when logging is everyone's job, because everyone's job means no one's job.
Where AI notetaking earns its place is here: AVAY's AI participant keeps notes and decisions current while people are still talking, so the raw material for an entry — what was decided, what was floated and dropped — exists without anyone stopping to type it. Someone still has to shape that into a proper log entry with rationale and a reopening trigger; the AI can surface what happened, but the judgment about why it matters and when to revisit it is still a person's call.
A decision log works best as its own document or table — a spreadsheet, a wiki page, a dedicated tool — indexed by decision, not by date or meeting. If it lives inside meeting notes, it inherits the same problem notes have: to find a decision, you have to know roughly when it happened. An index by topic or project area means someone can search "pricing" or "data retention" and get every relevant decision regardless of which meeting produced it.
Keep it short deliberately. A log with fifty-word entries gets read; a log with three-paragraph entries gets skimmed once and ignored afterward. If an entry needs more context than five or six lines, link out to the fuller discussion — a transcript, a doc — rather than pasting it in.
| Captures | Useful lifespan | Organized by | |
|---|---|---|---|
| Meeting notes | Discussion, tone, who said what | Days to a couple of weeks | Meeting / date |
| Formal minutes | Attendance, motions, formal record | Compliance record, rarely reread | Meeting / date |
| Decision log | Decision, rationale, alternatives, owner | Months to years | Decision / topic |
Minutes are a chronological record of a meeting — attendance, what was discussed, sometimes verbatim statements — kept mainly for formal or compliance reasons. A decision log only records the outcomes: what was decided, why, and by whom, indexed by decision rather than by meeting, so it stays useful long after the minutes themselves are irrelevant.
One person per meeting series, usually whoever runs the meeting, should have explicit responsibility for entering decisions as they're made. Shared ownership without a named person tends to mean nobody logs anything, because everyone assumes someone else will.
Don't edit the old entry — add a new one that references it and states what changed and why. Keeping the superseded entry intact preserves the history of reasoning, which is often as useful as the current decision, especially if the change gets questioned again later.
Start now rather than trying to reconstruct history. Backfilling a handful of decisions that are still actively being questioned is worth the time; reconstructing everything from the last two years usually isn't, because the rationale has already faded from memory.
No. A shared spreadsheet or wiki table with columns for decision, rationale, alternatives, owner, date, and revisit trigger works fine. What matters is that it's searchable by topic and separate from regular meeting notes, not which tool holds it.
A decision log only earns its place if it captures why a choice was made, not just what was chosen — write the rationale down while it's still in someone's head, not after it's had a chance to fade.
Meetings that take their own notes, in the browser: avay.ai.