Mental Model Mismatch Repair¶

Detect and repair mismatches between a person's mental model and how the system actually behaves.

Solution archetype #: 625
Problem family: Representation, Classification & Model Misfit
Problem subfamily: Model Assumption, Regulation & Residual Refinement

The Diagnostic Story¶

Symptom: The same errors recur even after training, and incident narratives contain phrases like 'I thought it would.' Users create workarounds that fight the system rather than use it, and explanations that seem perfectly clear do not stick. The gap between expected and actual behavior keeps generating friction that could have been resolved if its source had been diagnosed.

Pivot: Make the expected behavior explicit, compare it with observed or demonstrated actual behavior, diagnose the source of the divergence, choose the right correction locus -- model, system, or both -- and test whether future expectations are corrected.

Resolution: Predictions become more accurate, repeated errors decrease, and trust calibration improves. Training transfers because learners now hold a model that matches system behavior. The mismatch remains observable so drift can be caught before errors return.

Reach for this when you hear…¶

[aviation training] “The student keeps pulling back when the stall horn sounds because they are applying car-driving intuition -- until we directly surface that model and contrast it with how lift actually works, the correction will not hold.”

[EHR implementation] “The nurses keep clicking the wrong button because they expect the save to happen on navigation, not on explicit submit -- the system needs to either match the expectation or make the actual behavior unmissable.”

[DevOps] “Developers keep thinking the staging environment behaves like production until something breaks on Friday evening -- we need to either make the difference legible or reduce the difference, not just add another warning they will ignore.”

When This Archetype Applies¶

How to read this section

The block below states, in plain logic, when the archetype applies.

Diagnostic problem: the situation the archetype responds to.
Applicability expression: the conditions that make up that situation. and means both must hold; or means any one is enough. Numbers (1, 2, 3) mark conditions that hold together; capital letters (A, B) mark alternative groups, any one of which completes the pattern.
Grounded, partly grounded, open: whether an entry in this encyclopedia captures the condition. Lower-case letters (a, b, c) list those entries. Open means no matching abstraction has been found yet; the condition still counts.
Coverage: how many of the conditions are grounded.

The methodology explains how the conditions and their groundings were built. A worked example is stop 3 of the guided tour.

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

Users, operators, learners, or decision-makers take actions based on a mental model whose predictions diverge from actual system behavior, producing error, frustration, unsafe action, poor adoption, or repeated miscoordination.

What this problem means

The structural problem is a divergence between a predictive internal model and the system’s real behavior. The person’s model may be internally coherent, but it no longer fits the environment. Because action is organized around that model, ordinary reminders or more information often fail; the actor continues to anticipate the wrong state transition, exception, delay, consequence, or cue.

This mismatch can be hard to see because the person’s behavior may look careless from the outside. The archetype reframes the behavior as model-following. What matters is not only that an error occurred, but that the error reveals a specific prediction: “I thought it would save,” “I thought the scan filtered the list,” “I thought fallback was automatic,” or “I thought this forecast had already updated.”

Show the applicability expression

Applicability expression3 distinct conditions

Violated system predictionandActionable prediction mismatchandExplanation-resistant mental model

Algebraic1∧2∧3

groundedpartly groundedopen

3 conditions, all required.

3Required in every casenumbered 1–3

These hold no matter which pattern applies.

1

Violated system prediction · grounded

An active prediction about system behavior is observably violated by what occurs.

and — also required

2

Actionable prediction mismatch · grounded · any one of 5

The prediction mismatch changes user or operator action and causes error, frustration, unsafe behavior, or miscoordination.

and — also required

3

Explanation-resistant mental model · open

Repeated explanations fail to produce a durable correction in the actor's predictive model.

Other requirements and context (1)

Why these sit outside the expression

Solution feasibility — it describes whether the intervention can work, not whether the diagnostic problem exists.

Solution feasibilityThe system is learnable or alterable.

Coverage

2 of 3 conditions grounded · 1 open.

Read the methodology Download the trigger-logic data

Mechanisms / Implementations¶

Documentation Revision: Rewrites the reference text — stale wording, missing examples, hidden edge cases — so the correct model is retrievable at the moment of action.
Expectation Audit: Traces where an expectation, label, or score enters a process and maps the behavior channels through which it may be quietly manufacturing its own confirmation.
Incident Mental-Model Review: Reconstructs what operators believed during a real failure, infers what the system actually did from triangulated traces, and diagnoses why the two diverged.
Interface Affordance Redesign: Changes the labels, defaults, previews, and status cues a system emits so it stops inviting the wrong expectation, repairing the system rather than blaming the user.
Simulation-Based Correction: 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.
Training Feedback Loop: Turns recurring expectation failures across a population into revised training and monitors whether the same mismatch keeps coming back.
Usability Testing: Puts fresh users in front of the system, asks what they expect before they act, and records what it actually does — turning the expected-versus-actual gap into observed evidence.
User Journey Diagnostics: Traces a whole sequence of touchpoints to find where a wrong expectation accretes, mapping the assumptions that build up when no single screen or message created the mismatch alone.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

Feedback: Outputs influence inputs.
Mental Model: Internal system representation.
Representation: Model complex ideas.

Also references 6 related abstractions

Adaptation: Systems adjust to conditions.
Cognitive Load: Mental effort.
Metacognition: Awareness of thinking processes.
Observability: Infer internal state externally.
Observer Effect: Observation alters system.
User-Centered Design: Focus on user needs.

Variants¶

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Interface Expectation Repair · implementation variant · recognized

Repair mismatches created or reinforced by interface cues, labels, defaults, or affordances.

Operator Model Retraining · domain variant · recognized

Repair outdated or incomplete operator expectations about a machine, process, policy, or operational environment.

Reasonable Expectation System Alignment · risk or failure variant · candidate

Repair the mismatch by changing the system or process to match a reasonable user expectation rather than changing the user.

Editorial Notes¶

Problem Classification¶

Classification: Representation, Classification & Model Misfit → Model Assumption, Regulation & Residual Refinement

Problem kernel: mental model predictions diverge from system behavior

Rationale: Earliest causal condition: Users, operators, learners, or decision-makers take actions based on a mental model whose predictions diverge from actual system behavior, producing error, frustration, unsafe action, poor adoption, or repeated miscoordination.

Independent corroboration: The earliest necessary condition in the frozen evidence is: Users, operators, learners, or decision-makers take actions based on a mental model whose predictions diverge from actual system behavior, producing error, frustration, unsafe action, poor adoption, or repeated miscoordination. That is a model assumption regulation and residual refinement problem because A working model drives prediction or intervention despite mental-model mismatch, untested dynamics, systematic residuals, or invalid extrapolation.

Review outcome: Independent reviewer agreement; high confidence.