Simulation-Based Correction¶
Experiential simulation — instantiates Mental Model Mismatch Repair
Lets people live the mismatch safely in a realistic replica, rehearse the corrected model, and prove it transfers to a new scenario before real consequences occur.
Simulation-Based Correction repairs a mismatch by having the person experience it. In a realistic replica of the system — a simulator, a sandbox, a scripted scenario — the learner is led to the point where their model predicts wrongly, watches the true behavior unfold with no real stakes, and then rehearses the corrected model until it is retrievable under pressure. Its defining move is experiential rather than expository: it does not tell someone the right model, it stages the surprise and lets them internalize the correction through action, then closes the loop by transfer-testing them on a new case to prove the repair took. That validation step is what separates it from every other repair here — it is the mechanism that not only installs the corrected model but demonstrates it holds in a scenario the learner has not seen before.
Example¶
Airline pilots hold a model that the autothrottle will always wake up and add power if airspeed decays on approach. On one aircraft type, in a particular idle-descent mode, it will not — and a crew that trusts the wrong model can let speed bleed off dangerously. In a full-motion simulator, instructors stage exactly that configuration: the crew flies a normal approach, expects the autothrottle to intervene, and instead watches airspeed sag while nothing happens. The surprise lands with no one at risk. The crew then rehearses the corrected model — this mode does not protect speed; monitor and add power manually — flying the scenario until the manual intervention is reflexive. Finally, the instructor runs a different approach, at a different airport with different weather, to check that the crew now predicts the autothrottle's behavior correctly in a case they were not drilled on. Passing that unfamiliar case, not reciting the rule, is what counts as repaired.
How it works¶
- Build a faithful-enough replica. Reproduce the system behavior that triggers the mismatch with enough fidelity that the learner's real model is engaged.
- Stage the surprise. Lead the learner to the prediction point and let the true behavior contradict their expectation, safely and vividly.
- Rehearse the corrected model. Have them act on the right model repeatedly until it is available under time pressure, not merely understood.
- Transfer-test on a new case. Validate with an unfamiliar scenario the learner was not drilled on — the proof that the model, not the specific drill, was repaired.
Tuning parameters¶
- Fidelity — how closely the replica matches reality. Higher fidelity engages the true model and transfers better, but costs more to build and can distract with irrelevant detail.
- Surprise intensity — how sharply the simulated behavior violates the expectation. A vivid surprise cements the correction but an overwhelming one can induce startle rather than learning.
- Repetition count — how many rehearsals before the model is treated as installed; more builds reflexive retrieval at the cost of time and possible overfitting to the drill.
- Transfer distance — how different the validation scenario is from the practice one. A distant test proves genuine model repair; too distant and failure may reflect novelty, not a broken model.
When it helps, and when it misleads¶
Its strength is that it repairs models that only action can reach — the ones people can recite correctly yet still act against under pressure — and it is the one repair here that ships with its own proof, validating transfer to a fresh case. It is the standard antidote to automation surprises[1], where an operator's model of what a machine will do quietly diverges from what it does.
Its failure mode is a repair overfitted to the drill: rehearse one scripted scenario enough and the learner masters that scenario while the underlying model stays fragile, which is exactly why the transfer test must use a case the learner has never seen. Its classic misuse is false objectivity — a high-fidelity simulator makes the rehearsed model feel complete and certain, so learners forget it is still an approximation with boundaries. The guarding discipline is to vary the practice cases, always validate on genuinely novel scenarios, and mark the corrected model's remaining uncertainty rather than letting the simulator's realism imply there is none.
How it implements the components¶
model_revision_path— installs the corrected model experientially: the learner rehearses the right prediction and action until it is reflexive, not merely stated.expectation_validation— its signature step: a transfer test on an unfamiliar scenario proves the repaired model lets the learner predict correctly in a new case, not just repeat the rule.
It rehearses and validates the corrected model but does not fix the reference text or the system's cues: it leaves the words to Documentation Revision (assumption_map) and the affordances to its near-twin Interface Affordance Redesign (correction_locus_decision), both of which share the model-revision work but neither of which transfer-tests it. It also does not run the standing population-level loop (feedback_capture_loop, recurrence_monitor, Training Feedback Loop).
Related¶
- Instantiates: Mental Model Mismatch Repair — Simulation-Based Correction installs and validates the corrected model through safe experience.
- Consumes: Documentation Revision or Interface Affordance Redesign — supplies the corrected model that the simulation rehearses and puts to a transfer test.
- Sibling mechanisms: Usability Testing · Incident Mental-Model Review · User Journey Diagnostics · Interface Affordance Redesign · Documentation Revision · Training Feedback Loop · Expectation Audit
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Simulation-Based Correction operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it lets people live the mismatch safely in a realistic replica, rehearse the corrected model, and prove it transfers to a new scenario before real consequences occur.
Independent corroboration: The frozen evidence defines Simulation-Based Correction as 'Lets people live the mismatch safely in a realistic replica, rehearse the corrected model, and prove it transfers to a new scenario before real consequences occur', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Education & Pedagogy
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Experiencing a mismatch safely, rehearsing a corrected model, and testing transfer is simulation-based instructional remediation.
Related originating lineages:
- Aviation & Aeronautics — Scenario training verifies correction under varied operational conditions.
- Medicine & Healthcare — Clinical simulation corrects hazardous misconceptions before patient contact.
- Psychology — Prediction error and deliberate practice drive mental-model revision.
Review resolution: The blind reviewers agree that education_pedagogy is the primary origin and differ only on alternate origin disagreement, origin mode disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined evidence shows material contributions from several lineages. The broader reach of multi_domain records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
References¶
[1] Sarter, N. B., Woods, D. D., & Billings, C. E. "Automation Surprises". In G. Salvendy (Ed.), Handbook of Human Factors and Ergonomics, 2nd ed., pp. 1926–1943. John Wiley & Sons (1997). Explains automation surprises as mismatches between operators’ expectations and actual automation behavior. registry ↩