Skip to content

Incident Mental-Model Review

Retrospective review — instantiates Mental Model Mismatch Repair

Reconstructs what operators believed during a real failure, infers what the system actually did from triangulated traces, and diagnoses why the two diverged.

Incident Mental-Model Review is the mechanism you reach for when the mismatch only became visible after something broke. It reconstructs what the operators believed the system would do at each decision point during a real outage, near miss, or accident, infers what the system actually did from logs and records, and explains the divergence. Its defining move is retrospective and forensic: the failure is over and cannot be re-run, so instead of observing behavior it reconstructs it from evidence — and it treats the operators' actions as rational given the model they held, rather than as carelessness. Its object is not "who erred" but "what predictive rule made this action look correct at the time, and where did that rule part company with reality."

Example

A cloud platform suffers a two-hour partial outage when a regional database fails over. Afterward, the review does not start with "the on-call engineer made a mistake." It starts by reconstructing the belief that drove the action: the engineer expected failover to be automatic and instantaneous — that is what the runbook implied and what the last three incidents had done. The traces tell a different story: failover required a manual promotion step that had been quietly changed in a config update six weeks earlier, and the automatic path silently no-op'd. The review reconciles timestamps from the alerting system, the deploy log, and the engineer's own account, and lands the diagnosis on the gap: the operator's model of "failover is automatic" was correct until a system change made it stale, and nothing surfaced the change. The output is a documented mismatch — believed-automatic versus actually-manual, caused by an unannounced config drift — that repair mechanisms can then act on. The review itself proposes no fix.

How it works

  • Reconstruct the belief, not the blame. For each key action, recover what the operator predicted would happen — from their account, the runbook, and prior incidents — before hindsight rewrites it into "obvious."
  • Infer actual behavior from traces. Because the event cannot be observed live, assemble what the system truly did from logs, telemetry, and change records.
  • Triangulate before trusting. Cross-check testimony against independent traces; where they disagree, the discrepancy is itself a finding.
  • Diagnose the divergence. Name the specific cause — a stale model after a change, a hidden state, a missing exception — not a generic "human error."

Tuning parameters

  • Reconstruction depth — a single decision point or the full timeline of beliefs. Deeper reconstruction finds latent model errors but costs interview and analysis time.
  • Evidence triangulation — how many independent sources must agree before a claim about actual behavior is accepted. More sources resist a convenient story but slow the review.
  • Blame stance — how strictly the review holds to reconstructing local rationality versus drifting toward individual fault; the former is harder and fairer.
  • Scope of adjacent probing — whether to test nearby predictions the same model would also get wrong, catching a deeper error rather than one incident.

When it helps, and when it misleads

Its strength is that it recovers a mismatch that no controlled test would have staged, and it does so under the discipline of local rationality[n1] — assuming the operator's action made sense given their model, which is exactly what keeps the diagnosis honest and fair.

Its failure mode is hindsight: once the outcome is known, the wrong prediction looks foolish and the "cause" looks obvious, tempting the review to stop at the nearest human action. Its classic misuse is the blame-terminated postmortem — "operator failed to follow procedure" — which records a scapegoat instead of a mismatch and guarantees recurrence. The guarding discipline is to insist on reconstructing what was knowable at the time, to triangulate every claim about actual behavior against independent traces, and to probe adjacent predictions so a deep model error is not mistaken for a one-off slip.

How it implements the components

  • expected_behavior — reconstructs the operator's in-the-moment prediction at each decision point, recovered from testimony, runbooks, and prior incidents before hindsight distorts it.
  • mismatch_diagnosis — explains the specific divergence (here, a model made stale by an unannounced change), not a generic "human error."
  • evidence_check — triangulates testimony against logs, telemetry, and change records, treating any disagreement as itself a finding.

Because the failure is over, it does not observe the system live (actual_behavior) the way Usability Testing does with fresh users; and it root-causes one discrete event rather than mapping the assumptions that accrete across a whole path (assumption_map, User Journey Diagnostics, its other near-twin). It stops at diagnosis — it neither chooses nor performs the repair (correction_locus_decision, model_revision_path).

Editorial Notes

Form Classification

Form family: Assessment, Review & Assurance

Rationale: Incident Mental-Model Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it reconstructs what operators believed during a real failure, infers what the system actually did from triangulated traces, and diagnoses why the two diverged

Independent corroboration: The frozen evidence defines Incident Mental-Model Review as 'Reconstructs what operators believed during a real failure, infers what the system actually did from triangulated traces, and diagnoses why the two diverged', so its operative form is Assessment, Review & Assurance.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution

Primary origin: Engineering & Design

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Reconstructing local rationality from traces after accidents belongs to human-factors and safety-engineering investigation.

Related originating lineages:

  • Aviation & Aeronautics — Retained as a formative lineage because the independent reviewer identified it as primary: Reconstructing operator belief through local rationality descends from modern aviation and human-factors accident investigation.
  • Computer Science & Software Engineering — Logs and complex-system outages provide a major modern application.
  • Psychology — Mental-model and hindsight-bias research explain how knowledge and cues shaped action.

Review resolution: NASA human-factors material frames incident analysis around local rationality: why actions made sense to operators given their information and mental models. Aviation supplies the empirical setting, but the mechanism is a human-systems engineering review of designed-system interaction. The retained alternate domains identify independent or materially shaping provenance, not downstream reach alone. domain_reach=multi_domain because the mechanism has independent established use in several fields. The entry generalizes an established mechanism without inventing a new cross-domain composite.

Review outcome: Researched adjudication after independent review; high confidence.

Sources consulted:

Notes

[n1] Local rationality (Sidney Dekker's "new view" of human error) holds that people's actions make sense given their goals, knowledge, and focus at the moment — so a good review reconstructs the situation as it looked from the inside rather than judging it against the outcome the reviewer already knows.