Evidence before explanation

1944. Lesson identity

Module

4.16 — Postmortems

Lesson

Evidence before explanation

Academic type

Concept

Schema type

text

Order

1

Estimated time

35–45 minutes, including practice

1945. Learning objective

After this lesson, you can organize a student-project incident into a fact-based timeline, impact statement, contributing conditions, and root-cause hypothesis while labeling assumptions and unresolved questions.

1946. Why this matters

A postmortem is useful only when it helps a team make a better decision about its process or game. If you begin with a confident story, you may record blame instead of evidence and fix a symptom instead of the condition that allowed the incident. Clear separation of facts, assumptions, and hypotheses gives an AI collaborator or human teammate material that can be checked. It also turns a confusing failure into a reusable learning artifact.

1947. Prior knowledge

You should have completed 4.15 — Budgeting, including Build a decision-ready budget. You should be able to distinguish an observed project result from a forecast, assumption, or decision. No specific CONTRABAND incident is required for this lesson.

1948. Core concept

A postmortem should move from what was observed to what was affected, then to which conditions contributed, and finally to a root-cause hypothesis that remains open to testing.

These categories answer different questions:

• Timeline: What happened, and when?
• Impact: What changed for the player, project, team, or decision?
• Contributing conditions: What circumstances made the incident more likely or more costly?
• Root cause: What underlying condition, if changed or controlled, would be expected to prevent recurrence?

A root cause is not automatically the first cause in time, the person who made the last mistake, or the most memorable explanation. It is a claim that must be supported by evidence and connected to a prevention or detection action.

1949. Mental model

Use the Evidence Ladder:

A useful rule is: write the evidence first, label the uncertainty, and explain only as far as the evidence allows. If a statement cannot be checked, do not silently present it as a fact.

1950. Concrete example

Imagine a student team discovers that its latest playable build is missing after a work session.

A premature explanation might say: "The programmer forgot to commit, so the team lost a day."

An evidence-first account is more precise:

• Timeline: At 10:00, the team opened the project. At 12:15, the build was playable. At 13:00, an asset import was started. At 13:20, the editor closed unexpectedly. At 13:30, the team reopened the project and found that the latest scene changes were absent.
• Impact: The team could not demonstrate the current playable state and spent the next work session reconstructing changes.
• Observed facts: The local project folder contains the earlier scene version. The work-session notes contain no backup entry. The repository contains no commit after the earlier scene version.
• Assumptions to test: The asset import caused the loss. The missing commit would have restored all of the lost work. The editor closed because of a particular asset.
• Contributing conditions:
  • Bounded inference: No recovery checkpoint is visible in the supplied work-session notes or repository history.
  • Hypothesis: The workflow did not require a recovery checkpoint before a risky import.
  • Open question: Did another backup or recovery path exist outside the supplied notes and repository?
• Root-cause hypothesis — Hypothesis: The project workflow lacked a verified recovery checkpoint before operations that could damage or replace the current state.

Notice that the hypothesis does not accuse a person. It points toward a process change that can be tested: define a checkpoint before risky operations and verify that the checkpoint can restore the project.

1951. Common mistake

The most common mistake is to convert a plausible explanation into a recorded fact. A postmortem may say, "The import corrupted the scene," even when nobody inspected logs or reproduced the failure. Another mistake is to call "someone made a mistake" the root cause. That description may be true at one level, but it does not explain why the workflow allowed one mistake to create the observed impact or why the mistake was not detected earlier.

1952. Guided practice

Create a four-part incident note from the following scenario:

A student team planned to test a new enemy encounter on Friday. The encounter was not ready during the session. The team had spent most of the morning adjusting enemy animation timing. At 16:00, the team decided the encounter would be moved to the next session. No playable test was recorded that day. On Monday, the team discovered that the animation changes also altered the enemy's attack timing.

Write four sections:

1. Timeline: List only events with a stated time or clearly bounded order.
2. Impact: Describe the concrete effect on the game test and the project decision.
3. Contributing conditions: Identify at least two conditions, marking each as fact or assumption.
4. Root-cause hypothesis: Write one testable explanation that points to a process or system condition rather than a person.

Then mark every sentence in your note with one of these labels: Fact, Inference, Assumption, or Open question. Make one decision: choose the single earliest checkpoint or observation that would have reduced the uncertainty most, and explain why.

1953. Practical assessment and worksheet

Use the supplied scenario or a documented incident from your own project. Do not invent missing project history. Copy and complete this worksheet:

Incident:
Evidence sources consulted:

1. Bounded timeline
- [Fact / Inference / Assumption / Open question] Event and time or bounded order:

2. Impact
- [Label] Concrete effect on the game, project, team, or decision:

3. Contributing conditions
- [Label] Condition 1:
- [Label] Condition 2:

4. Root-cause hypothesis
- [Hypothesis] Testable process or system explanation:
- [Open question] Unresolved question:
- Proposed checkpoint:
- Why this checkpoint would reduce uncertainty or impact:

Root cause versus symptom: A symptom is the observed failure or impact. A contributing condition is a process or system circumstance that made the incident more likely or costly. A root-cause hypothesis proposes a testable relationship between such a condition and recurrence; it is not a final fact until evidence supports it.

Score the completed worksheet from 0 to 2 in each category:

The practical assessment is complete at 6 of 8 points or higher, with no score of 0 for Evidence status or Causal restraint. The lesson quiz remains a separate recognition check.

1954. Validation / evidence

Your work is complete when you can point to:

• A timeline that does not contain unsupported motives or causal claims.
• An impact statement that names a concrete consequence rather than an emotional reaction.
• At least two contributing conditions with their evidence status identified.
• One root-cause hypothesis that could be tested through a workflow change, reproduction, or additional observation.
• One open question and one proposed checkpoint that would improve the next investigation.

A strong submission does not need to identify a final cause. It must make the boundary between evidence and explanation visible.

1955. Key takeaways

• Facts describe what can be checked; assumptions and hypotheses must be labeled.
• A timeline establishes sequence but does not, by itself, prove causation.
• Impact describes the consequence for the game, project, team, or decision.
• Contributing conditions explain vulnerability; a root-cause hypothesis identifies a condition worth testing and changing.
• Evidence-first writing reduces blame and produces better corrective decisions.

1956. Next lesson

Next: 4.16 L2 — Write an actionable postmortem, where you will use this evidence structure to define corrective actions and follow-up checks.

1957. Knowledge check