KM-201b · Module 1

Decision Capture: Recording Not Just What Was Decided, But Why

4 min read

Organizations document decisions constantly. Every meeting has minutes. Every project has a status tracker. Every architecture review produces a recommendation. What almost none of these documents capture is the reasoning: the options that were considered, the criteria that were applied, the information that was available, and the explicit tradeoffs that were made. Two years later, when the decision needs to be revisited, all anyone can find is what was decided — not why — and the people who were in the room have moved on.

Decision capture is the practice of recording the full context of a significant decision as a structured artifact at the time the decision is made. It is not a retrospective analysis — by the time someone thinks to document the reasoning, most of the context has decayed. It is a real-time practice embedded in the decision-making process itself.

The highest-value decision records are for decisions that are difficult to reverse, expensive to re-derive, or likely to be questioned in the future. Architectural decisions in software systems were the original domain for this practice (Architecture Decision Records, or ADRs, emerged from the software engineering community). The same pattern applies to any organizational domain: a product strategy pivot, a pricing model change, a vendor selection, a market entry or exit, a hiring policy change.

The decision record format captures six elements. Context: what situation or problem prompted this decision? Options: what alternatives were considered — not just the chosen one, but all seriously evaluated alternatives with their tradeoffs. Decision: what was decided and the primary reasoning. Consequences: what outcomes are expected and what tradeoffs were explicitly accepted. Status: is this decision current, superseded, or deprecated? Owner: who is responsible for this decision and its consequences going forward.

  1. Context Field What was the situation that required a decision? Write this in enough detail that someone reading the record in two years can reconstruct the circumstances without additional context. Include the relevant constraints, pressures, and information that were available at the time. A context field that says 'needed to choose a database' provides no useful information. A context field that describes the scale requirements, team expertise, budget constraints, and integration requirements gives the future reader the full picture.
  2. Options Field Every option that received serious consideration — not just the one chosen. For each option: what were its advantages, what were its disadvantages, and why was it not chosen? This is the field that is most commonly skipped and most valuable. When the chosen option later shows a weakness, the options field tells you whether the alternatives were evaluated and rejected for reasons that are still valid, or whether one of them might now be the right answer.
  3. Decision and Consequences Fields What was decided, and what tradeoffs were explicitly accepted. The consequences field should include both the expected positive outcomes and the explicitly accepted negative tradeoffs. 'We chose the faster implementation at the cost of higher operational complexity' is a consequence field that accurately represents the decision. 'We chose the best option' is not a consequence field — it is a rationalization.

Decision capture must be embedded in the process that produces decisions, not bolted on as an afterthought. The most effective implementation is a decision record template in the project management or meeting workflow that is filled in before a decision is finalized, not after. When the decision record is part of the approval process — the decision is not considered finalized until the record is complete — capture happens consistently. When it is a post-hoc documentation request, it happens infrequently and poorly.

AI assistance changes the economics of decision capture significantly. A well-structured meeting agenda combined with a transcript can be processed by an AI system to produce a draft decision record in seconds. The decision-makers review, correct, and approve the draft — total additional time investment is five minutes rather than thirty. At that cost, the resistance to decision capture drops dramatically. The tooling is available now; the implementation barrier is process design, not effort.