The meeting decision log: a format that compounds

Hermann Ebbinghaus's forgetting curve, from the 1880s and replicated many times since, describes memory for new material decaying sharply in the first hours and then levelling off. The precise numbers depend on the material — his experiments used nonsense syllables, and meaning slows the decay considerably — but the shape holds, and anyone who has tried to write up a Monday meeting on Wednesday has felt it.

Meetings degrade in a particular order, which is what makes them worse than the curve suggests. The conclusion survives longest, because it is short and gets repeated. The reasoning goes first: which alternatives were considered, what the objection was, what would make the group revisit it. And the reasoning is the load-bearing part — a decision without it cannot be re-evaluated when circumstances change, so the team either defends it out of inertia or reopens it from scratch.

Three costs follow, and all three are familiar:

• Re-deciding. The same question returns to an agenda weeks later and consumes another meeting, usually reaching the same answer with less information.
• Divergent memories. Two people leave the same meeting with different accounts of what was agreed, and neither is lying. This surfaces at the worst moment, when the work is already built.
• Unexplainable state. Someone asks why the architecture works this way, and the only available answer is that it always has.

The format is deliberately minimal, because every column you add reduces the chance the log gets filled in at all.

The reasoning column is the one people drop first and the one that gives the log its value. "We chose Postgres" is a fact that anyone can read off the codebase in a year. "We chose Postgres over DynamoDB because the query patterns were relational and the team had no DynamoDB experience — revisit if write volume exceeds 10k/sec" is a decision that can be re-examined against reality. The second version also contains its own expiry condition, which is the highest-value sentence in any log.

The status column earns its place by making one thing visible: decisions that were made and never acted on. A log that is all "Decided" and no "Done" is telling you something more useful than any of its individual rows.

One decision, one line. The temptation is to write a paragraph capturing the nuance of the discussion. Resist it: a log of paragraphs is a document nobody scans, and a log nobody scans is not consulted at the moment it would help. If the nuance matters, it belongs in the transcript or the linked document, with the log pointing at it. The line is an index entry, not a record.

Every decision has one named person. Not a team, not two people, not "we." The reason is not accountability theatre — it is that a decision owned by a group has nobody whose job it is to notice it has not happened. A single name also gives everyone else a person to ask, which is what stops the question returning to a meeting agenda. If a decision genuinely has no owner, it was not a decision; it was a conclusion.

Two supporting habits: write the line before leaving the meeting, while the reasoning is still available at zero cost, and phrase it so someone outside the room can read it. "Go with option B" means nothing in six weeks even to the people who said it.

A log is a record; a reviewed log is a feedback loop. Once a quarter, an hour with the whole thing open produces four things that are hard to get any other way:

• Decisions still marked "Decided" months later. Either they were not real decisions or they lost to something else. Both are worth naming.
• Reasoning that no longer holds. The expiry conditions you wrote are now testable. Write volume did exceed 10k/sec; the decision is due for review, and you know that because someone wrote it down in April.
• Which meetings produce decisions. Sorting the log by source meeting ranks your recurring meetings by output, which is the honest input to a meeting audit.
• Patterns in what gets reversed. If reversals cluster in decisions made late in the day or with two people present, that is a fixable property of how you decide, not bad luck. See decision fatigue on a meeting-heavy calendar.

Anywhere the team already looks, and in a format that will outlive the tool. A markdown file in the repo, a single long-lived document, or one file per quarter all work. What matters is that there is exactly one, that it is append-only, and that it is not inside a product you might stop paying for — a decision log's value is a function of its age, so a format that lasts ten years is not a hypothetical requirement. That argument in full is in plain files beat platform lock-in.

Resist the urge to split it by project or team. The lookups that matter are chronological and textual — "what did we decide about pricing, at some point last year" — and one searchable file answers those in a way that a tidy hierarchy does not.

The reason decision logs fail is never that people disagree with the idea. It is that filling one in requires remembering, at the end of a meeting-heavy day, what six meetings decided and why — and reconstruction is the expensive part. The log gets three lines on Monday, one on Wednesday, and nothing after that.

Passive capture removes the reconstruction. Earkeep records mic and system audio continuously while it runs and transcribes locally on your device, so the full record of a meeting exists as it ends — no bot to invite, no start/stop to remember. Meetings are defined afterwards by selecting a span on a timeline, or automatically from a connected calendar; audio is processed only in memory and never written to disk. Writing the log line becomes reading and confirming rather than recalling, which is the difference between a habit that survives a bad week and one that does not.

It also makes the reasoning column feasible. Reasoning is the first thing to fade and the most tedious to reconstruct, and it is sitting verbatim in the transcript. An agent reading the day's transcripts can draft the log lines — decision, reasoning, owner — leaving you to correct a draft; the transcript stays as the source anyone can check the summary against. See meetings after the fact and agents and MCP.

The decision log is one of the outputs every meeting should produce; the others are in never leave a meeting empty-handed. For the full loop from conversation to result, see meeting workflows.

Download Earkeep free for macOS and write your decision log from the record instead of from memory.