The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
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.
After accumulating 10+ post-action reviews, analyze them in aggregate to identify structural causes appearing across multiple unrelated tasks—these recurring patterns indicate systemic tendencies requiring architectural fixes not isolated corrections.
Insert independent verification checkpoints at every coupling point where one process automatically consumes another's output without review to interrupt error cascade chains before they amplify.
For every important recurring process, design three explicit operating modes—full, reduced, and minimal—where each preserves progressively less fidelity but never loses continuity.
Define transition triggers for each operating mode that specify when to shift from full to reduced, reduced to minimal, and—critically—from degraded back to full operation.
Test degraded operating modes during periods of abundant resources to verify they preserve core function, because modes that fail under calm conditions will certainly fail under stress.
Practice running processes in degraded mode occasionally even when not required to rehearse partial failure, making the transition familiar rather than frightening when real constraints force it.
For every important process, document five components of recovery: failure mode specification, detection trigger, ordered recovery steps, recovery time target, and verification check.