The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
When an edge case breaks your schema, extract the implicit boundary condition that the edge case revealed rather than dismissing the edge case as an irrelevant exception.
Before explaining your schema to another person, frame your request as 'tell me where this breaks' rather than 'do you agree' to shift the conversation from validation theater to genuine testing.
Validate each atomic component of a compound schema independently before trusting the complete structure, because compound failures provide no diagnostic information about which component broke.
When using indirect evidence, assess whether indicators are genuinely independent by checking if they could agree for reasons other than the schema being true—if all evidence shares a common causal source, it counts as single evidence despite multiple data points.
After accumulating multiple validation records, analyze them as a set to identify recurring patterns in how your schemas fail—same blind spot, same overconfidence direction, same boundary condition—that no single test reveals.
Reformulate validated schemas with explicit boundary clauses that specify the conditions under which they were tested and the conditions under which they remain untested.
Schedule schema reviews at cadences matched to environmental volatility: weekly/biweekly for high-change contexts, monthly/quarterly for stable contexts, plus triggered reviews when surprises occur.
Treat surprising outcomes as automatic triggers for schema review rather than waiting for scheduled validation cycles, as surprise signals that at least one schema in your stack has drifted from reality.
When validating schemas about personal capability or performance, include external observer ratings alongside self-assessment to detect systematic overconfidence blind spots that introspection cannot reveal.
Run a pre-mortem on each critical schema by specifying what the early warning signs would look like if that model is becoming obsolete, then check whether you have already seen some of those signs.
Before attempting to update a deeply-held schema, explicitly restate it as 'I hold the belief that [X]. This belief is a model I use. It is not who I am.' to create cognitive distance between identity and the belief.
After updating a belief, identify one downstream decision where the revised model produces a different recommendation than the old one to ensure the update becomes operational rather than merely verbal.
When updating a schema, map all downstream dependencies (habits, commitments, tools, relationships, routines) before implementation and migrate high-friction dependencies first.
Before finalizing any schema update, list five situations where the old schema produced accurate results and verify the new schema handles all five to ensure backwards compatibility.
Set a tolerance window of at least sixty seconds to sit with cognitive dissonance before attempting resolution, as premature resolution systematically favors existing schemas over new evidence.
Set prediction failure thresholds as numeric ratios (X failures out of Y recent predictions) for each schema before observing prediction outcomes to trigger review when the threshold is crossed.
Define environmental change triggers by listing key assumptions underlying each schema and specifying observable indicators that each assumption no longer holds.
Accumulate anomalies (observations that don't fit the schema) in a running list and trigger full schema review when the count reaches a pre-defined threshold, rather than treating each anomaly as requiring immediate action.
Create a dedicated anomaly log separate from regular notes where each entry records what you expected, what happened, and which schema generated the expectation.
Assign review cadences to schemas based on their pace layer—weekly to monthly for fashion/commerce layers in complex domains, quarterly for infrastructure layer, annually for governance layer, and only on anomaly for culture/nature layers with high dependency depth.
When a schema has many downstream dependencies, apply slower and more deliberate revision cadences than its pace layer alone suggests, because updating foundational schemas requires cascading updates to all dependent schemas.
In complex or chaotic Cynefin domains, increase schema review frequency beyond what the pace layer suggests because unpredictability generates more frequent anomalies requiring evaluation.
Schedule schema reviews on actual calendars at the assigned cadence rather than relying on subjective feelings of uncertainty to prompt reconsideration.
When attempting to shift a shared team schema, create low-cost experiments where the team uses the new schema on one real decision, rather than presenting the new framework in slides or documents.