Concepts
The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types
Accumulate anomalies on a running list — trigger schema…
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.
Keep a separate anomaly log with three fields
Create a dedicated anomaly log separate from regular notes where each entry records what you expected, what happened, and which schema generated the expectation.
Map review frequency to pace layer
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.
High-dependency schemas need slower revision — each update…
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 domains, review schemas more…
In complex or chaotic Cynefin domains, increase schema review frequency beyond what the pace layer suggests because unpredictability generates more frequent anomalies requiring evaluation.
Put schema reviews on your actual calendar — subjective…
Schedule schema reviews on actual calendars at the assigned cadence rather than relying on subjective feelings of uncertainty to prompt reconsideration.
Shift team schemas through shared experiments…
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.
Before changing a team schema, map what it supports…
Before attempting to change a shared team schema, map what the current schema supports—which decisions it enables, what coordination it simplifies, and what would break if it disappeared—to understand its load-bearing function.
Schema change scales with group size
Scale your timeline expectations for schema change with group size—weeks for pairs, quarters for 50-person orgs, years for industries—and measure progress in behavioral change rather than stated agreement.
When your framework can't even formulate the right…
When your schema can no longer formulate the questions you need to ask about a domain, treat this incommensurability as a signal that the framework itself has become a cage requiring replacement.
Log schema changes with 4 fields
Write schema evolution log entries with four mandatory fields - date, schema affected in original language not current interpretation, specific triggering evidence or encounter, and the replacement belief - to defeat hindsight bias through fixed external records.
Keep schema evolution logs minimal (4 fields) and review…
Maintain schema evolution logs with minimum viable entries of four fields - date, schema affected, what changed, and what prompted the change - reviewed weekly, to generate a dataset about cognitive patterns that introspection alone cannot produce.
A schema unreviewed for 6 months is like an unupdated…
Treat any schema that has gone six months without deliberate review the same as a software dependency unupdated for six months - not necessarily broken but requiring verification before continued reliance.
Structural schema change is genuine growth; adding…
Measure personal development quality by asking whether any practice changed a schema's structure or merely added information to existing schemas - structural change is genuine growth, information addition is not.
Document what the old belief was protecting — the lost…
For each evolved schema, document not just old and new versions but also what the old belief was protecting or enabling, because identifying the lost function reveals emotional costs of revision and increases honesty about unrevised beliefs.
An unfalsifiable schema is a belief system, not a model…
When a schema cannot specify any observation that would falsify it, classify it as a belief system rather than a testable model and flag it for replacement or constraint.
Require 3 recent decision examples for each schema — fewer…
In your schema inventory, require behavioral proof by identifying three decisions from the last month that each schema governed—if you cannot find three, reclassify the schema as aspirational rather than operational.
Map schema dependencies in both directions…
For each important schema, map both its prerequisites (what it depends on) and its dependents (what depends on it), then flag schemas appearing most frequently as dependencies for regular review.
When two schemas both hold after evidence review, build…
When schema conflict persists after examining evidence, build a conditional routing rule specifying the exact conditions under which each schema applies rather than attempting to pick a universal winner.
Ask 'how long have similar tasks taken?' not 'how long…
When planning task duration, deliberately switch from inside-view scenario construction to outside-view base-rate consultation by asking 'how long have similar tasks taken?' instead of 'how long will this take?'
Track where each schema came from — prioritize…
For each schema you operate on, document source provenance in a single field—specific person, book, cultural norm, direct experience, or unknown—then prioritize verification effort by source weakness.
Evaluate sources by searching about them, not by reading…
Apply lateral reading by immediately opening new tabs to search for independent information about a source rather than evaluating the source by reading the source itself, because external assessment outperforms internal coherence checking.
When AI suggests a framework, ask for sources, boundary…
When AI assistants suggest frameworks or schemas, respond by asking for original research sources, boundary conditions, and strongest counterarguments rather than accepting or rejecting the claim directly.
Limit metacognitive recursion to two levels during live…
During real-time execution of high-stakes tasks, defer metacognitive recursion beyond two levels to avoid working memory saturation—externalize to enable deeper inspection.