Thermal-Runaway Incident Review

An incident review is not a hunt for somebody to blame.

It is an attempt to reconstruct a system well enough that the next team does not repeat the same failure path.

For this lesson, you will work from a fictional battery incident packet. No live battery is involved. Your job is to separate observation from inference, build a timeline, identify contributing conditions, and defend a safer future decision.

The incident packet

Assume the teacher provides these records:

• a storage-bin photo from the day before the incident;
• a battery ID label;
• a short team equipment log;
• a charger setup screenshot;
• two witness statements;
• a room-layout diagram;
• a post-incident note saying the pack was removed from student use and handled by adults under school procedure.

The fictional event is simple:

During preparation for a training session, a pack became unusually hot while connected to charging equipment. The team stopped the activity and escalated the situation. No student was injured.

Do not add details that are not in the packet.

Observation is not explanation

Start by sorting statements into two columns.

This distinction is the backbone of incident analysis. If you mix observations and explanations too early, the timeline turns into a story you already decided to believe.

Reconstruct the timeline

Use only times or ordering supported by the packet.

A good incident timeline might look like this:

The timeline does not prove root cause. It tells you where to look for contributing conditions.

Proximate cause versus contributing conditions

In engineering reviews, the final visible event is rarely the whole explanation.

A useful distinction is:

• proximate cause — the event immediately connected to the failure;
• contributing condition — something that made the failure more likely, harder to detect, or harder to manage;
• control failure — a safeguard that was missing, unclear, or ineffective;
• unknown — an important question the evidence cannot answer.

For this fictional case, you may not have enough evidence to identify the electrochemical root cause. That is fine.

You may still identify process-level issues such as:

• prior impact history was recorded but not clearly tied to a hold-for-review status;
• setup documentation was incomplete;
• storage status did not make abnormal equipment visually distinct;
• the team relied on “worked last time” as a readiness signal.

Those are actionable even without pretending to know exactly what happened inside the cells.

Worked review: one claim at a time

Consider this claim:

The previous hard landing caused the heating event.

Can the packet prove that?

Probably not.

A stronger statement is:

The prior hard landing is a relevant contributing condition because it created a damage history that should have triggered additional review before the pack returned to normal service.

That sentence does three things correctly:

1. it uses the evidence that actually exists;
2. it avoids claiming an unproven internal failure;
3. it still identifies a process improvement.

That is what bounded technical writing looks like.

Controls should interrupt the chain earlier

The goal of corrective action is not “tell everyone to be more careful.” That is too vague to test.

A better corrective action changes the system.

Examples for the fictional scenario:

A control is stronger when another team can follow it without needing the original incident witnesses in the room.

Your incident review artifact

Create a one-page battery incident review with five sections:

1. Timeline

List the supported sequence of events.

2. Confirmed observations

Use only evidence from the supplied packet.

3. Possible explanations

Label these clearly as hypotheses, not facts.

4. Contributing conditions

Identify process, storage, configuration, labeling, or review conditions that weakened the system.

5. Corrective controls

Recommend two changes that would catch the problem earlier or make the decision boundary clearer.

Finish with one sentence beginning:

The evidence supports...

and one beginning:

The evidence does not prove...

Those two sentences are your guardrail against turning an incident report into fiction.

The bigger lesson

A safe team is not a team that never sees abnormal equipment. Real systems age, get damaged, get mislabeled, and collect incomplete histories.

A safe team is one that notices when the normal model no longer fits, stops treating uncertainty like permission, and leaves enough evidence for the next decision to be better.

That is why incident review belongs in engineering. The point is not to sound official after something went wrong. The point is to make the system harder to fool the next time.