Write an actionable postmortem

1958. Lesson identity

Module

4.16 — Postmortems

Lesson

2 — Write an actionable postmortem

Academic type

Guided Build

Schema type

practical

Order

2 of the module

Estimated time

50–70 minutes, including practice

1959. Learning objective

After this lesson, you can write a blameless postmortem of your own student work that separates observations from explanations, makes bounded causal claims, assigns actionable ownership, and defines how each follow-up action will be verified.

1960. Why this matters

A postmortem is useful only when it changes the conditions that produced a problem. A timeline alone may describe what happened, but it does not establish what should change next. In AI-assisted development, a postmortem also prevents vague conclusions such as “the AI broke the project” or “the developer should have checked better.” The goal is to preserve evidence, reason carefully about causes, and create follow-up actions that another person can verify.

1961. Prior knowledge

You should already have completed 4.16 L1 — Evidence before explanation. You should be able to distinguish an observation from an interpretation, identify the source of a claim, record uncertainty, and avoid treating an unverified hypothesis as a fact. You also need a concrete piece of your own student work to analyze: for example, a failed implementation, a rework episode, a rejected test result, or a recovery from a broken state.

1962. Core concept

An actionable postmortem connects four layers without collapsing them into one:

1. Evidence: What can be checked directly?
2. Causal reasoning: Which conditions plausibly contributed, and how certain is that conclusion?
3. Ownership: Who will perform or coordinate the response?
4. Prevention and verification: What will change, and what evidence will show that the change worked?

A postmortem should analyze the system of work rather than assign a personal verdict. Blameless does not mean consequence-free or vague. It means describing decisions, conditions, interfaces, tools, checks, and assumptions instead of attacking a person's character.

1963. Mental model

Use the E-C-O-V chain:

A useful action has the form:

Owner will change or perform [specific behavior or artifact] by [defined boundary], verified by [observable pass condition].

Avoid actions that only express intent, such as “be more careful,” “use AI better,” or “test everything.” Those statements do not identify a behavior, owner, or verification method.

1964. Concrete example

The following is a provided teaching scenario for rehearsal, not a report of a real CONTRABAND incident or studio event. Use it to practice identifying evidence, separating causal claims, and drafting E-C-O-V actions. The milestone artifact you submit for this lesson must be based on your own student work; do not submit this scenario as your postmortem. If you use the scenario during rehearsal, treat only the facts stated here as available evidence and do not add imagined logs, dates, motives, or project history.

Suppose a student is building a small interaction and discovers that the interaction works in one test scene but fails after opening the project again. The available evidence is:

• The interaction succeeds immediately after the initial edit.
• It fails after reopening the project.
• A required scene reference is missing after reopening.
• The student has no record showing that the reference was checked before the first test.
• The cause could involve an unsaved editor state, an incorrect serialized reference, or an incomplete test procedure. The evidence does not establish which one with certainty.

A weak conclusion would be:

The student rushed, trusted the AI, and forgot to save.

This assigns motive and blame without proving either. A bounded conclusion is stronger:

The missing scene reference was present during the initial test but absent after reopening. The evidence establishes a persistence failure. The specific contribution of an unsaved editor state versus an incorrectly serialized reference is not established. The first test also lacked a reopen-and-retest step, so the workflow did not detect the failure before the work was considered complete.

Possible follow-up actions:

• Student: Before marking the next interaction complete, add and perform a reopen-and-retest step in the feature checklist. Verify the action by inspecting the completed checklist and reopening the project; it passes only if the interaction succeeds and the required reference remains valid after a clean reopen.
• Student: Before the next implementation review, record the required scene reference and its expected state in the implementation notes. Verify the action by comparing the notes with the reopened project state; it passes only if the reference and expected state are documented and match the observed state.
• Reviewer or future self: Before accepting the interaction as complete, reopen the project, reproduce the interaction, and inspect the required reference. Verify the action with the recorded reproduction result; it passes only if the interaction succeeds and the reference remains valid after a clean reopen.

The example does not claim that one action caused the failure. It identifies an established failure, separates competing hypotheses, and creates a check that can detect recurrence.

1965. Common mistake

The most common mistake is writing the remedy before establishing the failure mode. This produces generic actions such as “add more testing” or “review AI output.” Start with the evidence and state what remains unknown. Then choose the smallest follow-up action that addresses an observed gap or tests an important hypothesis. If the evidence cannot support a causal claim, write that limitation explicitly rather than manufacturing certainty.

1966. Guided practice

Create the milestone postmortem from a real piece of your own student work. Do not use a problem that is still only hypothetical, and do not submit the provided teaching scenario as the milestone artifact.

First, use the provided teaching scenario as rehearsal if helpful: identify its observations, draft a bounded causal account, and test whether its actions include ownership and verification. Then produce a separate postmortem based on your own student work. Cite only records and observations you can actually verify. Your own artifact may analyze a failed implementation, a rework episode, a rejected test result, or a recovery from a broken state. Do not embellish either the rehearsal scenario or your own evidence with invented details.

Step 1: Define the incident boundary

Write a neutral title and a two-sentence incident statement. Include what was expected, what was observed instead, and where the analysis begins and ends. Do not include a person's name as the explanation.

Step 2: Build the evidence table

Record at least four observations from your own student work.

Use concrete sources: a reproduction, test output, project state, screenshot, recorded behavior, commit, or written instruction. If a source is unavailable, mark the claim as unverified instead of silently treating it as evidence. During rehearsal with the provided teaching scenario, identify the scenario statement that supports each observation rather than inventing a source that was not supplied.

Step 3: Construct the causal account

Write three short sections:

• Established: claims directly supported by the evidence.
• Likely contributors: hypotheses supported by some evidence but not proven.
• Not established: plausible explanations that require more evidence.

Include at least one explicit uncertainty. Use calibrated wording such as “the evidence shows,” “likely contributed,” “may have increased the risk,” or “cannot be determined from the available record.”

Step 4: Record the process-gap outcome

Record exactly one outcome supported by the available evidence:

• Established gap: identify a workflow condition that the evidence directly supports.
• Likely gap: label the proposed gap explicitly as a hypothesis rather than an established fact.
• No established gap: state that the available evidence does not yet establish a process gap.

Do not force the sentence “The work was allowed to proceed without detecting...” unless the evidence supports it. If the gap is only likely or cannot yet be established, define a concrete evidence-gathering check. Name the record, reproduction, comparison, or observation you will obtain and the result that would reduce the uncertainty.

Step 5: Describe impact and scope

State who or what was affected and describe the observable consequences. Limit the scope to effects supported by cited evidence; distinguish confirmed impact from possible impact and record any scope that remains unknown.

Step 6: Reconstruct relevant decisions

For each decision relevant to the incident, record:

• the person or role that made it;
• the information available at that time;
• the assumptions or constraints that shaped it; and
• important unknowns that remained at the time.

Judge the decision from its contemporary information rather than from facts learned later.

Step 7: Write follow-up actions

Write two or three actions using the E-C-O-V format. Each action must include:

• an owner;
• a specific behavior or artifact to change;
• a practical boundary or completion condition;
• a verification method;
• a pass condition that another person could inspect.

At least one action must prevent recurrence, and at least one must improve detection if recurrence happens.

Step 8: State the learning boundary

End with two sentences:

1. What this postmortem supports us in claiming.
2. What it does not support us in claiming.

This prevents a small incident from becoming an unjustified general theory about the project, the tool, or the person who performed the work.

1967. Validation / evidence

Your milestone artifact is complete when it meets all of these checks:

• The incident statement describes an observable discrepancy between expected and actual behavior in your own student work.
• At least four observations have identifiable sources.
• Established facts, likely contributors, and unverified possibilities are separated.
• Impact identifies who or what was affected and limits the claimed scope to observable effects supported by cited evidence.
• Relevant decisions identify the decision-maker or role, the information available at the time, and important unknowns that remained.
• The process-gap section records exactly one permitted outcome: an established gap, a likely gap labeled as a hypothesis, or no gap currently established.
• A likely or unestablished process gap includes a concrete evidence-gathering check that could reduce the uncertainty.
• No sentence uses a person's character, effort, or intelligence as the causal explanation.
• Every follow-up action identifies an owner, a specific change, a completion boundary, a verification method, and an observable pass condition.
• At least one verification has a pass condition that can be repeated or inspected.
• The postmortem distinguishes a prevention action from a detection or recovery action.
• The final learning boundary names at least one claim that remains unsupported.
• The submitted artifact is based on your own student work, not only on the provided rehearsal scenario.

A peer or future reviewer should be able to read the document and answer: What happened? What do we actually know? Who or what was affected, and what observable scope does the evidence support? Which relevant decisions were made, with what information available at the time? What remained unknown then, and what remains uncertain now? Who will do what? How will we determine whether it worked?

1968. Key takeaways

• Evidence describes what can be checked; causal reasoning explains only what the evidence can support.
• The provided teaching scenario is for rehearsal; the milestone postmortem must use your own student work.
• Blameless analysis focuses on conditions and workflow gaps, while actionable ownership and observable verification define the response.
• A credible postmortem distinguishes prevention from detection and states the limits of its conclusion.

1969. Next lesson

Continue to 4.16 L3 — Assemble the Stage 4 evidence packet. Bring this draft and its evidence table forward so you can refine the analysis, test the follow-up actions, and assemble the evidence packet according to the curriculum sequence.

1970. Knowledge check