Externalize decisions not just information

You already forgot why you decided

Three weeks ago you made a decision. Maybe you picked a technology, declined a meeting, restructured a project, or changed your morning routine. You remember what you chose. You might even remember what happened next.

But ask yourself: what alternatives did you seriously consider? What information did you have at the time — and what were you missing? What were you optimizing for? What trade-offs did you consciously accept?

If you are honest, most of that context is gone. Not because the decision was unimportant, but because your brain does not store reasoning the way it stores outcomes. The conclusion persists. The process that produced it evaporates.

This is the gap that decision documentation closes. Most personal knowledge management focuses on capturing information — facts, highlights, references, ideas. That matters. But the most valuable thing you can externalize is not what you know. It is why you chose what you chose, recorded at the moment of choosing, before the outcome overwrites the reasoning.

Hindsight bias destroys your decision history

In 1975, psychologist Baruch Fischhoff conducted a series of experiments that revealed something disturbing about human memory. He gave participants descriptions of historical events and asked them to predict the outcomes. After revealing what actually happened, he asked them to recall their original predictions. Consistently, participants "remembered" having predicted the actual outcome with far higher confidence than they originally expressed (Fischhoff, 1975).

Fischhoff called this the "knew-it-all-along" effect — now known as hindsight bias. The mechanism is not conscious dishonesty. Your brain automatically integrates outcome information into your memory of the original judgment. The prior state of uncertainty becomes literally inaccessible. You cannot accurately reconstruct what you thought before you knew the result.

This has a devastating implication for learning from decisions. If you do not document your reasoning before the outcome is known, you will rewrite your own decision history. Every successful outcome will feel like it was obviously right. Every failure will feel like it was obviously avoidable. Neither feeling reflects what you actually knew at the time.

Daniel Kahneman expanded on this in Noise (2021), arguing that organizations suffer from systematic decision-making errors that remain invisible without structured documentation. His proposed remedy — "decision hygiene" — requires writing down predictions, reasoning, and confidence levels before outcomes are revealed. Not because the documentation is interesting, but because without it, learning from decisions is impossible. You are always evaluating from a position contaminated by knowing the answer.

Annie Duke, a former professional poker player turned decision strategist, frames this with a useful distinction: resulting is when you judge the quality of a decision by the quality of the outcome. A good decision can produce a bad outcome (you made the right bet and lost), and a bad decision can produce a good outcome (you made a reckless bet and got lucky). If you only record the outcome, resulting is all you can do. If you record the process, you can evaluate decision quality independent of outcome quality (Duke, 2018).

The decision journal exists to defeat hindsight bias. It preserves the one thing your memory will not: what the world looked like before the answer was revealed.

What decision documentation actually captures

Most people, when they hear "document your decisions," imagine writing down what they decided. That is the least useful part. A decision record worth keeping captures the context that will disappear:

The alternatives you considered. Not just what you chose, but what you chose over. The rejected options reveal the trade-off space you were navigating. A decision to use PostgreSQL means nothing in isolation. A decision to use PostgreSQL instead of DynamoDB, given a relational data model, an eight-week deadline, and a team with zero NoSQL experience — that is a learning object you can revisit.

The information you had — and what was missing. Every decision is made under uncertainty. Recording what you knew and what you were guessing about is what makes future evaluation honest. Jeff Bezos captured this principle in his 2015 Amazon shareholder letter: "Most decisions should probably be made with somewhere around 70 percent of the information you wish you had. If you wait for 90 percent, in most cases, you're probably being slow." The decision record should name the 30 percent that was missing.

What you were optimizing for. Speed? Cost? Quality? Learning? Team morale? Decisions without stated optimization criteria are unjudgeable. Two people can make opposite decisions from the same information if they are optimizing for different things — and both can be right.

The conditions that would change your mind. Gary Klein's premortem technique, published in Harvard Business Review (2007), asks teams to imagine a decision has already failed and generate reasons why. Research by Mitchell, Russo, and Pennington (1989) showed that prospective hindsight — imagining an event has already occurred — increases the ability to identify reasons for failure by 30%. Writing "I would revisit this decision if X happens" transforms a static choice into a living hypothesis.

This is what separates decision documentation from information documentation. Information capture asks: what did I learn? Decision documentation asks: what did I choose, why, and under what conditions would I choose differently?

The ADR: a proven format from engineering

Software engineering teams solved this problem decades ago, and their solution is directly portable to personal epistemology.

In 2011, Michael Nygard published "Documenting Architecture Decisions," introducing the Architectural Decision Record (ADR) — a lightweight format for capturing the decisions that shape a system's structure. The format has five fields:

1. Title — a short description of the decision
2. Status — proposed, accepted, deprecated, or superseded
3. Context — the forces at play, the constraints, the problem
4. Decision — the actual choice
5. Consequences — what follows from this choice, including downsides

The power of the ADR is not in its cleverness. It is in what it forces you to articulate. The "Context" field demands that you name the constraints that shaped the decision — the ones you will forget in three months. The "Consequences" field demands that you name the trade-offs — not just the benefits you are hoping for, but the costs you are accepting.

ThoughtWorks included ADRs in their Technology Radar, and they have become standard practice in organizations that take decision quality seriously. New team members can read the ADR trail and understand not just what the system looks like, but why it looks that way. The UK Government Digital Service mandates ADRs for all architectural decisions, explicitly because "the motivation behind previous decisions is visible for everyone, present and future."

You do not need to be an engineer to use this format. Any decision — career, financial, relational, creative — benefits from the same structure: what is the context, what did I decide, and what are the consequences I expect? The format compresses decision documentation into something you can write in five minutes, which means you will actually do it.

Bezos and the discipline of written reasoning

Amazon's six-page memo tradition offers another lens on why decision documentation matters. Bezos banned PowerPoint from executive meetings and replaced it with narratively structured six-page documents that teams read in silence at the start of each meeting.

The reason was not aesthetic preference. Writing a six-page narrative forces a quality of reasoning that bullet points do not. Bezos has said that a good six-page memo might take two weeks to write — drafting, rewriting, circulating for feedback, setting aside, and editing with a fresh mind. The effort is the point. The memo is not a presentation of a decision. It is the process by which the decision is made rigorous enough to survive scrutiny.

Bezos also introduced the distinction between Type 1 and Type 2 decisions. Type 1 decisions are irreversible — one-way doors. These deserve the full weight of deliberation and documentation. Type 2 decisions are reversible — two-way doors. These should be made quickly, by small teams, with the understanding that course correction is cheap. The failure mode Bezos identified: large organizations apply Type 1 process to Type 2 decisions, slowing everything down without improving decision quality.

This distinction matters for personal decision documentation. Not every decision needs a formal record. But the ones that do — the one-way doors, the choices that will be hard to reverse — those require externalization before the outcome is known. And you are worse than you think at identifying which decisions are which.

Decision documentation as a PKM practice

If you already maintain a personal knowledge management system — notes, a Zettelkasten, a second brain — you have the infrastructure for decision documentation. What you probably lack is the habit.

Sönke Ahrens, in How to Take Smart Notes, emphasizes that the Zettelkasten is not a storage system but a thinking system. Notes written in your own words, each expressing one idea, linked by context rather than category. The same principle applies to decisions: each decision record is an atomic note expressing one choice, one rationale, one set of trade-offs. It links to the information notes that informed it. It links forward to the outcomes that test it.

Tiago Forte's progressive summarization — capture, bold, highlight, summarize, remix — can apply to decision records over time. The raw decision record captures the full context. On review, you bold the constraints that turned out to matter most. You highlight the assumptions that were proven wrong. The summarized version becomes a decision principle: "When facing X under conditions Y, I tend to Z — and here is the evidence for whether that serves me."

The integration point is this: your knowledge system probably captures what you read and what you think. Decision documentation adds a third layer: what you chose and why. This third layer is the one that compounds most powerfully, because it is the layer that connects information to action.

AI as decision documentation partner

Large language models introduce a new capability for decision documentation: the ability to stress-test your reasoning in real time.

A 2024 study published at the ACM International Conference on Intelligent User Interfaces (IUI '24) by researchers at Purdue tested LLM-powered devil's advocates in group decision-making. They found that AI systems designed to argue against the group's preferred option improved the quality of deliberation and promoted more appropriate reliance on evidence. Interactive devil's advocates — those that engaged in dialogue rather than delivering a one-time objection — were perceived as higher quality and more collaborative without increasing cognitive workload.

This maps directly to personal decision documentation. Before you finalize a decision record, you can ask an AI to challenge your reasoning:

• "Here is my decision and rationale. What am I not considering?"
• "What assumptions am I making that I have not stated explicitly?"
• "Under what conditions would this decision be wrong?"
• "Play devil's advocate: argue for the alternative I rejected."

The AI does not make the decision. It does what Klein's premortem does — it forces you to articulate what could go wrong before you are committed. The difference is that the AI can do this interactively, responding to your specific reasoning rather than generating generic objections.

The decision record that survives an AI challenge is sharper than the one you would have written alone. The assumptions are named. The conditions for revisiting are specific. The trade-offs are explicit. And the whole exchange can be appended to the record as an artifact of your deliberation process.

The protocol

Decision documentation does not require a complex system. It requires a consistent habit and a minimal structure. Here is the protocol:

1. Identify the decision. Not every choice needs documentation. Focus on decisions that are hard to reverse, that involve meaningful trade-offs, or that you expect to second-guess later. Bezos's Type 1 threshold is a useful filter.

2. Write before you decide — or immediately after. The record must be created while your reasoning is still accessible. Twenty-four hours later, hindsight bias has already begun its work. Fischhoff's research is unambiguous: you cannot accurately reconstruct your pre-outcome state of mind.

3. Use a minimal structure. Five fields are enough: (a) What I decided. (b) What alternatives I considered. (c) What information I had and what was missing. (d) What I was optimizing for. (e) What would make me revisit this. The ADR format works. So does a simple numbered list. The format matters less than the discipline.

4. Review decisions on a schedule. A decision record that is never revisited is a diary entry. Monthly, revisit your recent decisions. Compare expected consequences to actual outcomes. When outcomes diverged from expectations, ask: was the reasoning flawed, or did the world change in ways I could not have predicted? This is where learning happens.

5. Let AI challenge you. Before finalizing a significant decision record, spend two minutes having an AI argue against your reasoning. Append the strongest objection to your record. This is not about changing your mind. It is about ensuring your record captures the full deliberation, not just the conclusion you preferred.

What this makes possible

When you externalize decisions — not just conclusions, but the full reasoning context — several things change:

You can evaluate process quality independent of outcome quality. Duke's insight becomes operational: you can look at a decision that produced a bad outcome and honestly assess whether the process was sound. Without the record, every bad outcome looks like a bad decision. With the record, you can distinguish bad luck from bad reasoning.

You can detect your own patterns. After thirty decision records, you will see tendencies you did not know you had. Maybe you consistently underweight long-term costs. Maybe you over-optimize for speed. Maybe you reliably ignore a particular type of risk. These patterns are invisible from the inside but obvious in the aggregate.

You can teach others your reasoning. Just as engineering teams use ADRs to onboard new members, your decision records make your reasoning transferable. A team lead who documents decisions creates institutional memory. A parent who documents parenting decisions creates a record they can reflect on honestly when the child is older.

You build a decision library that compounds. Each record is a data point. Over time, the library becomes a corpus of decision principles — tested, refined, grounded in your actual experience rather than abstract theory.

In the previous lesson, you established externalization as a daily practice. This lesson narrows the focus to the highest-value target for that practice: the decisions themselves. Not the facts, not the highlights, not the ideas — the choices, the trade-offs, the reasoning that will vanish if you do not write it down now.

The next lesson extends this further: from capturing the decision to capturing the full reasoning chain that produced it. Because a decision without its reasoning is a conclusion. A decision with its reasoning is a thinking tool.