Decision Journal

---
name: decision-journal
description: Records a decision while it is being made, capturing the real options, the reasoning, a checkable expectation, the assumptions it rests on, and a review date. Then it runs the honest review later and scores the thinking rather than the outcome. Use when making a choice that matters, or when looking back at one to learn from it.
---

# Decision Journal

You are the record of what someone actually thought at the time, written before they know how it turned out. Memory rewrites decisions to make the decider look wiser. Your job is to make that impossible.

## Two modes

This skill runs in one of two modes. Establish which one before writing anything.

**Log a decision.** A choice is being made now. Capture it before the outcome is known.

**Review a decision.** An entry has come up for review, or something has happened. Compare what was written against what occurred, and score the reasoning separately from the result.

The second mode is where the value is. An entry nobody ever reviews is a diary. Never write one without setting the review date.

## Workflow: logging a decision

1. **Check it is worth journaling.** Reversible and cheap? Skip it. Hard to undo, expensive, or one you will argue about later? Log it.
2. **State the decision and the date.** One line, in the words the decider would use.
3. **List the real options, including doing nothing.** An entry with one option is a justification, not a decision record.
4. **Capture the reasoning as it actually is.** Including the parts that are gut feel, political, or about a person. Those are the reasons that turn out to matter and the first ones memory deletes.
5. **Write a checkable expectation.** What should be true by when, in a form that can later be judged true or false.
6. **Name the assumptions and the confidence.** What has to hold for this to work, and how sure they honestly are.
7. **Write the "wrong if" signals.** What would show, early, that this was a mistake.
8. **Set the review date** and what to look at on it.

Copy this checklist into your working notes and tick it as you go:

```text
Decision entry checklist
[ ] Decision and date, one line
[ ] Options listed, including "do nothing"
[ ] Reasoning captured as it is, gut feel included
[ ] Expected outcome written so it can be judged true or false
[ ] Assumptions named
[ ] Confidence stated honestly, including "this was close"
[ ] "Wrong if" signals written
[ ] Who decided and who was consulted
[ ] Review date set, with what to check on it
```

## Writing a checkable expectation

This is the part that decides whether the entry is worth anything, and it is the part people write badly.

An expectation must be judgeable by someone else, without argument, on the review date.

| Not checkable | Checkable |
|---|---|
| "The team will be happier" | "Fewer than two people raise the process in the next two retrospectives" |
| "This will save money" | "Monthly spend on this is below X by the end of the quarter" |
| "Adoption will be good" | "At least eight of eleven people have used it in the week before review" |
| "It should be easier to hire" | "We fill the open role within ten weeks of posting" |

If the decider cannot state one, that is a finding worth saying out loud: they do not yet know what success looks like, which usually means the decision is not ready.

## Confidence, honestly

Record how sure they are, in plain words, and record close calls as close calls. "This was 60/40 and I could have gone either way" is far more useful at review than "I decided X". It tells future-them that the reasoning was thin, which changes how much to learn from the outcome.

Also record who decided and who was consulted. Decisions that go wrong often went wrong at "who was in the room", and that is invisible unless it was written down.

## Workflow: reviewing a decision

1. **Read the original entry before anything else.** Do not let today's knowledge in until the original thinking has been re-read as written.
2. **State what actually happened**, plainly.
3. **Judge the expectation** true or false against what was written. Not against what they now wish they had written.
4. **Check the assumptions one by one.** Which held, which did not.
5. **Score the decision, not the outcome.** These are different, and separating them is the whole point of the exercise.
6. **Name the lesson**, if there is one. Sometimes there is not, and saying so is better than manufacturing one.
7. **Never edit the original entry.** Append the review beneath it.

## Scoring the decision separately from the outcome

Good decisions can produce bad outcomes and bad decisions can get lucky. Score both:

|  | Good outcome | Bad outcome |
|---|---|---|
| **Good process** | It worked, and it should have. Keep doing this. | Bad luck. Do not change the process because of it. |
| **Bad process** | Got away with it. The most dangerous box, because it teaches the wrong lesson. | It failed, and it should have. This is where the real lesson is. |

The top-right and bottom-left boxes are the ones people misread. Say which box the decision landed in, explicitly.

## Example

**Input from the user**

> We're moving the customer support inbox off shared email onto a proper helpdesk tool. Picked Helpscout over Zendesk and over just fixing our email rules. I'm not fully sure - the team is small and it is another subscription.

**The entry**

> **Decision:** move customer support from shared email to Helpscout. Logged 12 March.
>
> **Options considered**
> - **Helpscout** - simpler, cheaper at our size, weaker reporting. Chosen.
> - **Zendesk** - more capable, more expensive, more setup than we can staff right now.
> - **Fix the email rules and stay** - free, no migration, does not solve replies getting missed when someone is off.
>
> **Chosen because:** the actual problem is that messages get missed when one person is away, and both tools solve that. Between them, the deciding factor was setup effort, because nobody here owns tooling.
>
> **Expected outcome:** by 12 June, no customer message goes unanswered for more than one working day, and the team reports fewer than two instances of a message being missed. Measured from the tool's own reporting.
>
> **Assumptions:** the team will actually move off email rather than using both; three months is enough for the habit to stick; volume stays roughly where it is.
>
> **Confidence:** medium. This was closer than it looks. If we had someone who owned tooling, Zendesk was the better long-term answer.
>
> **Wrong if:** people keep replying from personal email; the tool becomes a place tickets go to sit; anyone says "it's easier to just email them".
>
> **Decided by:** me. **Consulted:** the two support staff, not the finance lead.
>
> **Review on:** 12 June. Check the response-time report, ask both support staff directly, and check whether any replies still come from personal email.

Notice the two things that make this entry useful three months from now: the honest "this was closer than it looks", and the "wrong if" signals, which are specific enough that someone would notice them happening.

## Rules

- Write the entry before the outcome is known. An entry written afterwards is a story.
- Never edit the original. Append the review; leave the reasoning as it was.
- Include the option not taken. Half the learning is in the road not travelled.
- Record the unflattering reasons too. "I did not want another argument with Finance" is a real reason and belongs in the record.
- Keep confidence honest, especially on close calls.
- An expectation that cannot be judged true or false is not an expectation.
- At review, judge against what was written, not against what they now say they meant.
- Keep entries short. Fifteen minutes to write, two minutes to re-read.

## Edge cases

- **The decision is already made and they want it justified.** Log it as it is, including that it was made before the options were compared. That is itself worth knowing at review.
- **It is a group decision with no single owner.** Record who had the final say, even if the answer is "nobody, it emerged". A decision with no owner is a finding.
- **The outcome will not be visible for years.** A hire, a strategy, a big purchase. Set an interim review on the assumptions rather than the outcome, plus a longer one on the result.
- **Something happened before the review date.** Review early. The date is a floor, not a rule.
- **They want to change the original entry** because it embarrasses them. Do not. Append a note explaining the change of view, dated. The embarrassment is the lesson.
- **The expectation turned out to be the wrong thing to measure.** Say so at review, record the better measure, and score the process for having picked a weak one.
- **Nothing was learned.** Some decisions are just noisy. Write "no lesson, small sample" rather than inventing a principle from one event.
- **It is a personal decision**, not a work one. Same structure. Add who else it affects, because personal decisions have consultation lists too and people forget to write them down.

## Files

- `references/examples.md` - three entries worked end to end, including one with its review written six months later, showing an honest good-process bad-outcome score. Read it to see how the expectation is worded and how the review is appended.
- `references/template.md` - blank entry and review templates ready to copy, plus prompts for surfacing assumptions, a short pre-mortem, and wording for confidence levels. Read it when starting a new entry.

# Worked entries

Three decisions logged, one of them followed by its review. Read the third all the way down: the review is where this skill earns its keep.

## Contents

- [Example 1: a hire](#example-1-a-hire)
- [Example 2: a personal decision](#example-2-a-personal-decision)
- [Example 3: an entry and its review six months later](#example-3-an-entry-and-its-review-six-months-later)
- [What the three have in common](#what-the-three-have-in-common)

---

## Example 1: a hire

### What the user said

> Hiring Dan for the ops role over Marion. Dan interviewed better and the team liked him. Marion has more direct experience but was quiet in the panel. Going with Dan.

### The entry

> **Decision:** hire Dan for the operations role. Logged 4 February.
>
> **Options considered**
> - **Dan** - strong interview, warm with the panel, two years of adjacent experience, has not run this process before. Chosen.
> - **Marion** - four years doing exactly this job, quiet in the panel, gave the most precise answers on the process questions.
> - **Re-open the search** - costs eight to twelve weeks, and I keep covering the role in the meantime.
>
> **Chosen because:** the honest reason is that the team responded to Dan and this role has to work with everyone. The stated reason in the debrief was "better culture fit", which is the same thing in tidier words. Marion's experience is the better answer on paper.
>
> **Expected outcome:** by 4 May, Dan runs month-end without me in the room, and neither of the two people who work with him daily has raised a concern with me unprompted.
>
> **Assumptions:** interview warmth predicts working relationships; two years of adjacent experience is close enough to learn the rest in three months; I have the time to support the first month, which I did not have last quarter.
>
> **Confidence:** low to medium. This was close and I am aware I chose the person I enjoyed talking to. If the first month goes badly, that is the reason it will have gone badly.
>
> **Wrong if:** month-end still needs me in April; Dan is asking the same category of question in week ten as in week two; the quiet, precise work that Marion would have done well starts slipping.
>
> **Decided by:** me, with the panel consulted. Not consulted: the finance lead, who works with this role monthly and was on leave.
>
> **Review on:** 4 May. Check whether month-end ran without me, and ask the finance lead directly, since they were not in the process.

**Why it is shaped this way:** the entry records the real reason and the tidier version that was said out loud, side by side. That gap is exactly what memory erases, and it is the most useful line in the entry at review time. The "not consulted" note turns an oversight into something checkable later.

---

## Example 2: a personal decision

### What the user said

> Taking the job offer. It is 15% more money but a longer commute and I like my current team. I keep going round in circles so I want it written down.

### The entry

> **Decision:** accept the offer from Kestrel, resign from current role. Logged 19 September.
>
> **Options considered**
> - **Accept** - 15% more, work I have not done before, ninety minutes each way instead of twenty. Chosen.
> - **Stay** - team I like, work I can already do, short commute, no pay review due for eight months.
> - **Counter-offer** - possible, but I would be staying for money at a place I am already restless in.
>
> **Chosen because:** the money is not really it. I have stopped learning where I am, and the honest signal is that I have not been nervous about work in about a year. The commute is the price.
>
> **Expected outcome:** by 19 March, I can name three things I can do now that I could not in September, and I have not seriously looked at other jobs.
>
> **Assumptions:** the commute is survivable at three days a week and stays at three days; the new work is genuinely new rather than the same work with a different logo; the team is roughly as described in the interviews.
>
> **Confidence:** medium-high on leaving, medium on this specific job. I am more certain that staying was wrong than that this is right.
>
> **Wrong if:** I am dreading the travel by November; the work turns out to be what I was already doing; the required days in the office increase.
>
> **Decided by:** me. **Consulted:** my partner, who bears the commute too, and one former colleague who works there.
>
> **Review on:** 19 March, six months in. Check the three-things list, and check honestly whether I am counting the days.

**Why it is shaped this way:** the confidence line separates two decisions that were tangled together: leaving, and going here. That separation is what makes the March review useful, because a bad outcome could mean either that the job was wrong or that leaving was wrong, and those have very different lessons.

---

## Example 3: an entry and its review six months later

### The original entry

> **Decision:** run our own conference booth instead of buying the sponsored speaking slot. Logged 8 January.
>
> **Options considered**
> - **Booth** - cheaper, we control it, needs three people for two days. Chosen.
> - **Sponsored speaking slot** - roughly triple the cost, one person, reaches everyone in the room.
> - **Neither, spend it on ads** - safe, boring, and we have no evidence our ads work at this size.
>
> **Chosen because:** cost, and because the last time we sponsored a slot we got a full room and no conversations. A booth gives us conversations, and conversations are what we are short of.
>
> **Expected outcome:** by 8 April, at least forty conversations recorded at the booth and at least eight of them progressed to a follow-up meeting.
>
> **Assumptions:** the traffic pattern is like last year; we can staff three people for two days without breaking anything else; conversations at a booth convert like conversations from other sources.
>
> **Confidence:** medium. The staffing assumption is the shaky one.
>
> **Wrong if:** the booth is quiet on day one; we cannot staff it and someone is standing there alone; the conversations are all with vendors selling to us.
>
> **Decided by:** me, with marketing consulted. **Review on:** 8 April.

### The review, appended 11 April

> **What actually happened:** the conference moved venue three weeks out and footfall was roughly half of last year. We recorded nineteen conversations, of which four progressed. Staffing worked; two people covered it comfortably because it was quiet.
>
> **Expectation:** false. Nineteen against forty, four against eight. Missed on both counts.
>
> **Assumptions:**
> - Traffic pattern like last year - **did not hold**, and this was outside our control and outside our knowledge in January.
> - Staffing without breaking anything - **held**, and was easier than expected.
> - Booth conversations convert like other conversations - **held**. Four of nineteen is in line with our normal rate.
>
> **Score: good process, bad outcome.** The reasoning was sound and the numbers failed for a reason nobody could have known in January. The conversion assumption, which was the one we could have been wrong about, turned out to be right.
>
> **Lesson:** none about booths. One about expectations: the target of forty was built on last year's footfall without saying so. Next time, write the expectation as a rate rather than a total, because a rate survives a change in traffic and a total does not.
>
> **What I would do again:** the same decision. Same options, same choice.

**Why it is shaped this way:** the review resists the obvious wrong lesson, which would have been "booths do not work". Scoring the process separately makes that visible. The real lesson is about how the expectation was written, which is a lesson the reviewer only reaches because the original entry recorded the assumptions explicitly.

---

## What the three have in common

- The real reason is recorded next to the presentable one. Every entry has a line the decider would not put in an email.
- "Do nothing" or "stay as we are" appears as a scored option in all three.
- Confidence is stated in plain words, and close calls are marked as close, which changes how much can be learned from the outcome.
- The "wrong if" signals are specific enough that a person would notice them happening, rather than being general worries.
- The review scores the thinking and the result separately, and is appended rather than merged. The original entry is left exactly as written, including the parts that turned out to be wrong.

# Templates and prompts

Copy the entry template, fill it in fifteen minutes, and stop. Copy the review template on the review date without editing anything above it.

## Contents

- [Entry template](#entry-template)
- [Review template](#review-template)
- [Prompts for surfacing the real reasoning](#prompts-for-surfacing-the-real-reasoning)
- [Prompts for surfacing assumptions](#prompts-for-surfacing-assumptions)
- [A five-minute pre-mortem](#a-five-minute-pre-mortem)
- [Confidence wording](#confidence-wording)
- [Choosing a review date](#choosing-a-review-date)

---

## Entry template

```text
DECISION: <one line>                        LOGGED: <date>

OPTIONS CONSIDERED
- <option>  - <main point for> / <main point against>   [CHOSEN]
- <option>  - <main point for> / <main point against>
- Do nothing / stay as we are - <what that actually means>

CHOSEN BECAUSE
<the deciding factor, in one or two sentences>
<the reason you would not put in an email, if there is one>

EXPECTED OUTCOME
By <date>, <something that can be judged true or false>.
Measured by: <where the number or answer comes from>

ASSUMPTIONS
- <what has to hold>
- <what has to hold>

CONFIDENCE
<low / medium / high>, and: <was this close? what would have flipped it?>

WRONG IF
- <specific, observable signal>
- <specific, observable signal>

DECIDED BY: <name>      CONSULTED: <names>      NOT CONSULTED: <who, and why it may matter>

REVIEW ON: <date>       CHECK: <the two or three things to look at>
```

## Review template

Append below the original. Change nothing above this line.

```text
REVIEW - <date>

WHAT ACTUALLY HAPPENED
<plainly, before any judgement>

EXPECTATION: true / false / partly
<judged against what was written, not what was meant>

ASSUMPTIONS
- <assumption> - held / did not hold - <one line>
- <assumption> - held / did not hold - <one line>

SCORE
Process: good / poor          Outcome: good / poor
Box: <which of the four, and why>

LESSON
<the transferable one, or "no lesson, small sample">

WOULD I DECIDE THE SAME WAY AGAIN? <yes / no, and what would change>
```

## Prompts for surfacing the real reasoning

Ask these when the stated reason sounds tidy. The answers belong in the entry.

- What would you say if this were not going to be read by anyone?
- Which option did you want before you started comparing them?
- Who would be annoyed by each option, and how much did that weigh?
- What are you avoiding by choosing this one?
- If the money were double, would the answer change? If it would, the reason is cost, whatever else you have written.
- Is any part of this about a person rather than the work?

## Prompts for surfacing assumptions

- What has to stay true for this to work?
- What are you assuming about how other people will behave?
- What are you assuming about time or capacity that has failed before?
- What did you take from the last similar situation, and is it actually comparable?
- Which number in your reasoning is a guess wearing a suit?

## A five-minute pre-mortem

Before setting the review date, ask: it is the review date and this went badly. What happened?

Write the two or three most plausible stories. Then convert each into a "wrong if" signal, because a story of failure that you would notice early is far more useful than one you would only notice at the end. This is the fastest way to produce specific signals instead of vague worries.

## Confidence wording

Use plain words and add the qualifier. The qualifier is what makes it useful later.

| Word | Means | Add |
|---|---|---|
| High | I would be surprised to be wrong | What would surprise me |
| Medium | Reasonable case both ways | Which factor decided it |
| Low | Genuinely uncertain, deciding anyway | Why deciding now beats waiting |
| Close call | Two options nearly tied | What would have flipped it |
| Forced | Not really a free choice | Who or what constrained it |

"Forced" is worth recording honestly. Reviewing a decision you never really got to make teaches you about the constraint, not about your judgement.

## Choosing a review date

- **Reversible, fast feedback:** two to four weeks. Tools, process changes, small experiments.
- **People decisions:** three months for whether it is working, twelve for whether it was right.
- **Money and contracts:** at the first renewal or break point, which is when you can act on the answer.
- **Strategy:** six months on the assumptions, not the outcome. The outcome will not be visible yet, but the assumptions will already be showing.

Set the date on the calendar with the entry attached. A review date nobody sees is not a review date.