Twenty minutes into the meeting, someone frowns and says the sentence that should be printed on the conference-room wall: "Wait — didn't we decide this in March?" Silence. Somebody thinks so. Somebody else remembers it differently. The person who argued hardest in March has since left. So the team does the only thing available to a team with no memory: it has the March meeting again, reaches roughly the March conclusion again, and — this is the part that should sting — writes it down exactly as thoroughly as last time, which is to say not at all. See you in November.

Your knowledge base, if you have one, holds the how-tos: the SOPs, the setup guides, the answers to recurring questions. But a team's operating knowledge has a second species that almost nobody captures: the decisions. We invoice on the 1st, not on delivery. We don't discount past 15%. We chose this vendor over that one. Support replies come from a named person, never "the team." Each of those is knowledge with a timestamp and a reason attached — and at most small companies, the timestamp and the reason live nowhere except the fading memory of whoever was in the room.

What dying decisions actually cost

The meeting rerun is the visible cost, and it's the cheapest one. The expensive failures are quieter. Accidental reversal: a decision made for a good reason gets undone by someone who never knew the reason — the discount cap quietly breached by a new salesperson closing a deal, the vendor re-evaluated because nobody recorded why it won last time. The original problem, which the decision existed to prevent, returns on schedule. Rules without reasons: new hires inherit the decisions as folklore — "we just don't do that here" — which teaches compliance instead of judgment, and folklore can't be updated, only obeyed or ignored. And the authority fog: when nobody can point to where a decision was made, every past conclusion is reopenable by whoever feels strongly today, which means nothing is ever actually settled and the loudest recent voice outranks the best old reasoning.

The log: one line, five fields

The fix is deliberately tiny, because every heavyweight version of it dies. Software teams learned this years ago with architecture decision records; the operating version for a whole company is even leaner. One entry per decision, one line if you're disciplined:

Thirty seconds, written in the moment the decision lands — at the end of the meeting, in the thread where the call got made — and then copied to one home. Not scattered across meeting notes, chat scrollback, and someone's notebook: one place, chronological, searchable. The capture habit is the same one that fixes documentation debt: answer once, capture once — except here it's decide once, capture once, and the interest rate on the uncaptured version is even higher.

What earns an entry — and what doesn't

Log the decisions that bind future behavior: policies, standards, pricing rules, vendor commitments, anything someone six months from now could unknowingly violate or pointlessly re-debate. Skip the preferences and the one-offs — where the offsite happened, which title went on the blog post. The sorting test is reversibility-times-recurrence: a call that's expensive to reverse, or that the team will face again, goes in the log. A call nobody will ever need to remember doesn't. Most weeks produce one to three loggable decisions; if you're logging ten, you're minuting, not logging, and the log will die of weight like every meeting-minutes initiative before it.

The revisit date keeps old decisions honest

Here's the field that separates a decision log from a rulebook: every entry records the condition under which it should be reconsidered. Decisions are made against a context — a volume, a team size, a market, a constraint — and contexts drift. "No paid ads; CAC doesn't work below $2k deals" is a great decision at ten customers and possibly a terrible one at two hundred. Without the revisit condition, old decisions harden into dogma defended by people who've forgotten they were ever contingent — or get discarded wholesale by people who assume they were arbitrary. With it, the log becomes self-updating: a quarterly twenty-minute skim of the entries whose conditions have arrived, reopened deliberately instead of by ambush. That skim is also the single best onboarding document you own — "read the last twenty entries" hands a new hire the reasons behind the rules, which is the difference between hiring someone who follows your playbook and someone who understands it.

Where the tool fits

The decision log's failure mode is identical to every capture habit's: the moment of decision is exactly the moment everyone's attention has already moved to the next agenda item, and "someone should write that down" is where the entry dies. KnowledgeByDesign closes that gap the same way it closes it for answers: the conclusion of a thread or a meeting note becomes a structured entry — decision, reasoning, owner, revisit condition — in the same motion, filed in one searchable home alongside the how-tos, and surfaced when someone searches the question the decision already answered. The judgment of what's worth logging stays with you; the tool's job is making the thirty seconds actually take thirty seconds.

The bottom line

A team that documents its processes but not its decisions has written down how it works while forgetting why — and the why is the part that gets relitigated, reversed, and mythologized. One line per decision: what was settled, the reasoning with its rejected alternatives, who called it, and what would reopen it. Thirty seconds at the moment it lands, one home, a quarterly skim. It's the cheapest institutional memory you will ever build, and the first time someone answers "didn't we decide this in March?" with a link instead of a shrug, it will have paid for every entry you ever wrote.

— Tom

Make the thirty seconds take thirty seconds

KnowledgeByDesign turns a thread's conclusion into a structured decision entry — reasoning, owner, revisit condition — filed where the next person searching the question will actually find it.

See how KnowledgeByDesign works →

About the author

Tom Christian is the founder of KnowledgeByDesign, an AI-native knowledge platform that captures what your team knows before it walks out the door.

He has spent twenty years inside training, QA, and knowledge operations at scale — Guardian Life, ConnectiveRx, and Horizon Blue Cross Blue Shield's Service Division. He writes about knowledge bases that stay alive, SOPs people actually follow, tribal-knowledge capture, and the operating discipline of documentation without a department behind it.