The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
For each feedback mechanism you build, verify within the first cycle that the data reveals something unknown, that measurement effort is sustainable, and that you can specify one concrete adjustment based on results—if any component fails, redesign before continuing.
When a metric has been used to drive decisions for more than three months without revision, conduct a three-question audit: what behavior does this metric actually incentivize, is the proxy still correlated with the outcome, and what would gaming this metric look like compared to current behavior.
Retire metrics entirely when they no longer distinguish between gaming behavior and genuine progress, as continued use of a decoupled metric produces wrong information you trust rather than mere absence of information.
Treat major life or work transitions as mandatory recalibration events requiring review of all existing feedback loops, as changed context invalidates proxy-outcome correlations that held under previous conditions.
When improvement effort in a domain has stalled despite sustained attention, shift focus from single-loop correction (adjusting actions) to double-loop correction (questioning the framework generating actions) by explicitly listing and testing the assumptions underlying your approach.
When building any recurring system (workflow, habit, routine), design an explicit degraded-mode version that preserves core function at reduced scope before the system encounters its first disruption.
For each detected error in a system, explicitly classify whether it represents an execution failure (wrong doing), knowledge failure (missing information), or judgment failure (incorrect assessment) before designing any correction.
When an error recurs with the same root cause across multiple independent instances, apply structural fixes (process changes, environmental redesign, automated checks) rather than effort-based resolutions (increased attention, more discipline, trying harder).
For execution errors, deploy procedural corrections (checklists, automation, environmental forcing functions); for knowledge errors, deploy epistemic corrections (new information sources, expert consultation); for judgment errors, deploy calibrational corrections (prediction tracking, external review, pre-mortems).
Before committing significant resources to any project, list the 3-5 assumptions that would invalidate the most work if wrong, then design and execute the cheapest falsification test for each assumption in order of potential damage.
At each stage of a multi-phase commitment, calculate the cost ratio between discovering a foundational error now versus discovering it after the next phase completes—when this ratio exceeds 5:1, increase detection investment before proceeding.
Build error detection infrastructure that monitors both your primary outputs and your detection system's own performance, tracking what errors you catch versus what you miss through other means to detect detection failures.
Design measurement infrastructure before executing strategies rather than after problems become visible, because drift detection requires baseline instrumentation that must exist before deviation occurs.
For any system you operate, define four components in writing: (1) ideal behavior, (2) minimum acceptable behavior, (3) numeric deviation threshold, and (4) time window before triggering investigation.
When error budget exhaustion occurs in a tracked system, conduct root cause analysis of the pattern rather than investigating individual deviations, because budget exhaustion signals structural problems while individual errors within budget represent normal variance.
Express error budgets as time-bounded numeric thresholds (e.g., 'two missed sessions per week' or '30 minutes downtime per month') rather than vague intentions, and track consumption against the budget as a first-class metric.
Test root cause validity by asking whether eliminating the identified cause would make the error impossible rather than merely less frequent—if only frequency decreases, continue deeper analysis.
When asking 'why' produces multiple independent answers, branch the Five Whys analysis to follow each causal path separately rather than selecting one primary cause, because multi-causal problems require tree structures not chains.
Stop Five Whys analysis when you reach a cause you can structurally prevent, not at a predetermined question count—use five iterations as a heuristic but let actionability determine the stopping point.
Limit operational checklists to 5-10 items focused exclusively on steps most likely to be skipped or forgotten under load, not comprehensive process documentation.
Insert mandatory pause points in checklist execution where all activity stops and verification becomes the primary task, rather than running checklists as background processes.
For each checklist item, require a physical action (touching the control) or verbal callout (saying the condition aloud) to prevent autopilot execution where the ritual completes without actual verification.
Position pre-flight checks at the boundary between preparation and execution—after work is ready but before it begins—to catch errors when correction cost is minimal and propagation has not started.
For any pre-flight check item you can complete in under 5 seconds without pausing, treat that as evidence of ritual execution not genuine verification—pause and locate observable evidence before marking complete.