You've been running on an outdated model for months
Right now you're operating with at least one mental model that no longer matches reality. Maybe it's your framework for evaluating job candidates. Maybe it's your theory about why customers buy your product. Maybe it's your understanding of what motivates your team. The model was accurate when you formed it. The world moved. You didn't notice.
This is the default state for every human being. Not because we're careless, but because schemas are designed to run automatically. That's their value — they let you process information without rethinking everything from scratch. But that same automaticity means a schema can degrade for weeks or months before the accumulated errors become obvious enough to force your attention.
The fix isn't "be more vigilant." You can't monitor everything all the time. The fix is defining specific, observable conditions that trigger a review — tripwires that fire whether or not you feel like something is wrong. Engineers, scientists, and quality controllers solved this problem decades ago. It's time to import their solutions into how you manage your own thinking.
What quality control already knows about trigger conditions
Walter Shewhart invented the control chart at Bell Laboratories in the 1920s. His insight was deceptively simple: every process has natural variation, and you need a systematic method to distinguish normal fluctuation from a genuine signal that something has changed.
The Western Electric Company formalized this into four rules in their 1956 Statistical Quality Control Handbook. These rules define when a manufacturing process is "out of control" — when observed data deviates enough from expected patterns that you should intervene:
- A single point beyond 3 standard deviations from the center line — a dramatic outlier.
- Two out of three consecutive points beyond 2 standard deviations on the same side — a pattern forming.
- Four out of five consecutive points beyond 1 standard deviation on the same side — a subtle but persistent drift.
- Eight consecutive points on the same side of the center line — a slow shift that no single observation reveals.
Lloyd Nelson expanded these to eight rules in 1984, adding tests for trends, oscillation, and overcontrol. The principle remains constant: you define the conditions for intervention before the process starts running, not after you suspect a problem.
This is the core idea for schema review triggers. You define what "out of control" looks like for your mental models before you need to use the definition. A single dramatic prediction failure is Rule 1. A series of slightly-off decisions trending in one direction is Rule 4. You don't wait to feel uncertain. You set thresholds.
The pre-mortem: defining triggers prospectively
Gary Klein introduced the pre-mortem technique in a 2007 Harvard Business Review article, building on research by Deborah Mitchell, Jay Russo, and Nancy Pennington. Their 1989 study found that prospective hindsight — imagining that an event has already occurred — increases your ability to correctly identify reasons for outcomes by 30%.
The standard pre-mortem asks: "Imagine this project has failed. What went wrong?" For schema review, the adapted question is: "Imagine this mental model has become dangerously inaccurate. What would I observe?"
This is a fundamentally different question from "Is my model still good?" The first question asks you to generate concrete, observable signals. The second invites vague reassurance. When you imagine the failure as already having happened, you think about evidence differently. You picture the downstream effects — the decisions that went wrong, the predictions that missed, the people who stopped responding as expected.
Klein emphasizes that pre-mortems surface concerns people would normally suppress. Applied to schemas, the technique surfaces triggers you'd otherwise dismiss as unlikely or uncomfortable. "What if my entire theory of what motivates my team is wrong?" is a thought most managers won't entertain spontaneously. But in a structured pre-mortem, it becomes a trigger to define: if three team members in a quarter leave for reasons I didn't predict, review the motivation schema.
Bayesian surprise: when observations demand belief revision
Information theory offers a precise framework for when you should update your beliefs. Bayesian surprise measures the divergence between your prior expectations and what you actually observe — formally, the Kullback-Leibler divergence between your prior and posterior probability distributions.
You don't need the math to use the principle. The core idea: the degree to which an observation should trigger review is proportional to how unexpected it is under your current model.
If your schema predicts that customers churn primarily because of price, and you encounter one customer who left over a feature gap, that's low surprise — your model already accounts for some non-price churn. But if you encounter five customers in a row who left over feature gaps, the cumulative surprise is high. Your model assigned low probability to that pattern, and reality generated it anyway. That's a trigger.
This connects to a well-documented human bias. Research on conservatism in belief revision shows that people consistently underweight new evidence — they update their beliefs more slowly than Bayes' theorem prescribes. You're wired to explain away surprising observations rather than let them update your models. This is why you need explicit triggers: your intuitive sense of "that's surprising enough to reconsider" is systematically too conservative.
The practical application is tracking prediction accuracy. If your schema generates predictions (and every useful schema does, at least implicitly), keep a lightweight log of how often those predictions land. You don't need statistical rigor — a simple tally is enough. When your hit rate drops below a threshold you set in advance, that's a trigger.
Five trigger types for personal schemas
Drawing from quality control, pre-mortem analysis, Bayesian reasoning, and systems monitoring, here are five categories of triggers you can define for any schema you maintain:
1. Prediction failure threshold
Set a ratio: if more than X out of Y recent predictions based on this schema were wrong, review it. For a hiring framework, that might be "if 3 of the last 5 hires I rated highly underperformed in their first year." For a market thesis, it might be "if my revenue forecast misses by more than 20% two quarters in a row." The specific numbers depend on the schema's domain and your tolerance for error.
2. Environmental change detector
Define external conditions that would invalidate assumptions your schema depends on. Every schema is built on premises about how the world works. When those premises change, the schema needs review — even if it hasn't produced visible errors yet. A management schema built for in-person teams needs review when your team goes remote. A product strategy schema built for a growing market needs review when the market contracts. List the key assumptions. Define what would indicate each assumption no longer holds.
3. Time-based expiration
Some schemas degrade simply because the world moves. Set a calendar-based review regardless of observed performance. David Allen's GTD methodology includes a weekly review precisely because task contexts shift whether or not you notice. For slower-moving schemas, quarterly or annual reviews work. The key is that the review happens on schedule, not on feeling. Spaced repetition research confirms the principle: revisiting material at defined intervals strengthens accuracy and surfaces drift that gradual exposure masks.
4. Anomaly accumulator
Thomas Kuhn's account of scientific revolutions describes how anomalies — observations that don't fit the current paradigm — accumulate before triggering a paradigm shift. Crucially, no single anomaly causes the shift. It's the accumulation. Define a threshold for accumulated anomalies: small observations that don't quite fit, edge cases your schema handles awkwardly, situations where you had to override the schema's recommendation. Keep a running list. When the list hits a number you define in advance, trigger a full review. Kuhn observed that scientists don't abandon a paradigm until the anomalies become overwhelming and an alternative is available. You can be more proactive: review the schema when anomalies accumulate past your threshold, even before you have a replacement.
5. Stakeholder divergence signal
When people affected by your schema start behaving in ways it doesn't predict or explain, that's a trigger. If your leadership schema says transparent communication builds trust, and three team members stop sharing concerns in meetings, your schema and reality have diverged. The people closest to the schema's effects often detect problems before you do. Define whose behavior you'll monitor and what patterns would constitute a trigger.
Your third brain: automated triggers and drift detection
In machine learning operations, the problem of schema degradation has a precise name: model drift. ML engineers distinguish between data drift (the inputs change) and concept drift (the relationship between inputs and outputs changes). Both degrade model performance, and both require systematic detection because the model itself cannot tell you it's wrong.
The parallels to personal schemas are exact. Your mental models can degrade because the inputs you encounter have changed (you moved to a new market, a new role, a new relationship), or because the underlying dynamics shifted (what used to predict customer behavior no longer does). In both cases, the model keeps generating outputs. It just generates increasingly wrong ones.
ML monitoring systems solve this with automated drift detection: statistical tests that compare current data distributions against training data, performance metrics tracked against baselines, and automated retraining triggers when deviation exceeds a threshold. Google's Site Reliability Engineering framework takes a similar approach with error budgets — you define an acceptable failure rate, and when accumulated errors consume the budget, that automatically triggers intervention. You don't debate whether to intervene. The trigger is pre-committed.
If you use AI as a thinking partner — a third brain alongside your biological cognition and your externalized notes — you can implement literal automated triggers. Feed your schema's predictions and outcomes to a language model. Ask it to track your accuracy rate and flag when it drops below your threshold. Have it compare your current assumptions against recent information and surface contradictions. The AI doesn't need to be right about what your schema should become. It just needs to reliably fire the trigger.
Even without AI automation, the engineering mindset applies. Define your schema's SLO — its Service Level Objective, the minimum acceptable performance. Define the error budget — how much failure you'll tolerate before reviewing. Track actuals against that budget. When the budget is consumed, review. The system works because the trigger is defined before you need it, measured against observable evidence, and committed to in advance.
The protocol: set your triggers now
Define trigger conditions for your most important active schema using this template:
Schema: [Name the mental model, framework, or belief]
Trigger 1 — Prediction failure: Review if [X] out of [Y] predictions fail. Evidence source: [where you'd observe this]. Check frequency: [how often you'll look].
Trigger 2 — Environmental change: Review if [specific assumption] no longer holds. Evidence source: [what would indicate the shift]. Check frequency: [how often you'll verify].
Trigger 3 — Time expiration: Review every [interval] regardless of observed performance. Next review date: [specific date].
Trigger 4 — Anomaly accumulation: Review when [N] unexplained observations accumulate. Log location: [where you'll track them].
Trigger 5 — Stakeholder divergence: Review if [specific people] exhibit [specific behaviors] that the schema doesn't predict. Observation method: [how you'll notice].
You don't need all five for every schema. But you need at least two, and at least one must be independent of your subjective judgment. The entire point is that triggers fire when you wouldn't otherwise think to look.
What happens when a trigger fires
A trigger firing doesn't mean the schema is wrong. It means the schema has earned a review. Maybe the anomalies have a benign explanation. Maybe the prediction failures came from bad data, not a bad model. The review determines whether the schema needs modification, replacement, or simply re-confirmation with updated evidence.
But here's what you've now built: a system where your most important mental models are monitored, where degradation is detected early, and where review happens based on evidence rather than crisis. Most people only revisit their schemas after a painful failure makes ignoring the problem impossible. You'll revisit yours when the first signals appear — while correction is still cheap.
This sets up a direct question: once a trigger fires and you begin reviewing, what exactly should you look for? The answer is anomalies — and as we'll explore in the next lesson, anomalies aren't just noise to filter out. They're the raw material of schema evolution.