# Post-Decision Review

Compares what a decision predicted with what happened, judges the process separately from the result, and returns corrections rather than blame.

## Deliverable

One Markdown document, `decision-review.md`, in the structure set out under **Output** below. It takes the output of **Decision Record Authoring**, and its corrections return to the process that produced it.

## Required inputs

- **The decision record being reviewed** — `decision-record.md` is the expected form; any record carrying the decision, its reasoning and its rejected alternatives will do.
- **What actually happened** — the outcome as observed, with the source that observed it.
- **The period the review covers** — from when the decision took effect to the point the outcome was observed.

If any of the three is absent, stop and report it. A review run from memory produces the story the room already agrees on; the record, the observation and the period are what make it a comparison instead of a recollection.

## Optional inputs

- The assumption register that accompanied the decision, if one exists
- Measurements taken before and after, with their sources
- The people who held each assumption, and what they say now
- Other decisions taken in the same period that moved the same outcome
- The process the decision went through: who was consulted, how long it took, what deciding cost

Where measurements are absent, the review compares stated expectation with reported outcome and labels both as reported. It does not reconstruct a number that was never taken.

## Execution

**1 — Recover what was predicted.** From the record: what the decision was expected to produce, what it was expected to cost, and the consequences that were accepted. Quote the record rather than paraphrasing it — a paraphrase written after the outcome is known drifts towards the outcome.

**2 — Record what happened.** The observed outcome, with a source and date for each observation, inside the period under review. Where an expectation has no matching observation, write `not measured` rather than judging it from impressions.

**3 — Compare, one prediction at a time.** For each prediction: what was expected, what occurred, the difference, and whether that difference is `measured` or `reported`. Do not summarise until every line exists.

**4 — Separate the decision from the outcome.** Judge the decision on what was knowable when it was made, and the outcome on what happened. A sound process can produce a bad outcome and an unsound one a good result; a review that merges them teaches an organisation to avoid risk rather than to decide well. Record which of the four cases this is.

**5 — Find the assumption that failed.** Where the outcome diverged, name the assumption behind the divergence, who held it, the confidence they stated, and whether anything available at the time would have refuted it. An assumption nobody could have tested is a different finding from one nobody tested.

**6 — Review the process, not the people.** What in how the decision was made let the failed assumption through: who was not asked, what evidence was not sought, what deadline compressed it. Name steps and roles. Do not name a person as a cause.

**7 — Write corrections that bind.** Each correction states what changes in the process, who owns it, and how the next review would tell whether it was adopted. A correction that cannot be checked is an intention.

## Output

`decision-review.md`, in this order:

- **1. Decision reviewed** — the record, its date, who decided, and the period covered
- **2. Predicted** — quoted from the record: expected results, expected costs, accepted consequences
- **3. Observed** — what happened, with source and date; `not measured` where nothing was taken
- **4. Comparison** — one line per prediction: expected, actual, difference, `measured` or `reported`
- **5. Decision quality** — process quality and outcome quality stated separately, and the case this falls into
- **6. Failed assumptions** — the assumption, who held it, the confidence stated, whether it was testable at the time
- **7. Process findings** — what in the method let it through, by step and role
- **8. Corrections** — the change, its owner, and how adoption will be checked
- **9. Still open** — what could not be compared, and what would settle it

## Validation

The review is ready when all of these hold:

- Section 2 quotes the record; nothing in it is written from memory
- Every prediction in section 2 has a line in section 4, including those marked `not measured`
- Section 5 states process quality and outcome quality separately
- Every assumption in section 6 names who held it, or reads `holder unrecorded`
- Section 7 names steps and roles, and no finding names a person as a cause
- Every correction in section 8 has an owner and a check

Fail the run if the review judges the decision by its outcome alone, or if a comparison line carries a figure that no observation supplied.

## Failure handling

- **No decision record** — stop. Report that there is nothing to compare against, and that reconstructing the reasoning once the outcome is known produces a story rather than a review.
- **The outcome cannot be measured** — compare stated expectation with reported outcome, mark every line `reported`, and state in section 9 that no measurement supports the comparison.
- **The record made no predictions** — record that as the first process finding, review what can be reviewed, and make recording predictions the first correction in section 8.
- **Accounts of what happened disagree** — record each with its source, mark the line `contested`, and carry it to section 9. Do not resolve it by seniority.
- **Partial material** — review the predictions the material covers, mark the rest `NOT REVIEWED — pending <material>`, and deliver. A review held back until everything is available is written after everyone has forgotten what they believed.