Concepts
The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types
Validate new feedback mechanisms in the first cycle
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.
Audit decision-driving metrics every 3 months
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 that can't distinguish gaming from genuine…
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.
Major transitions require full feedback loop recalibration…
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 stalls despite effort, shift…
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.
Design a degraded-mode version of every recurring system…
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.
Classify errors as execution, knowledge, or judgment…
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.
Recurring errors with the same root cause need structural…
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).
Match correction type to error type
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).
Test your riskiest assumptions first and cheapest — list…
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.
When the cost of late error discovery exceeds 5x early…
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.
Monitor your error detection system itself — track what…
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.
Instrument before executing — drift detection requires…
Design measurement infrastructure before executing strategies rather than after problems become visible, because drift detection requires baseline instrumentation that must exist before deviation occurs.
Define your error budget in writing
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 is exhausted, analyze the pattern…
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 numbers with time windows — '2…
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.
A true root cause, eliminated, makes the error impossible…
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 'why' has multiple independent answers, branch…
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 at structural preventability…
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.
Checklists are 5-10 items that catch what competent people…
Limit operational checklists to 5-10 items focused exclusively on steps most likely to be skipped or forgotten under load, not comprehensive process documentation.
Checklists need mandatory pause points where all activity…
Insert mandatory pause points in checklist execution where all activity stops and verification becomes the primary task, rather than running checklists as background processes.
Require a physical touch or verbal callout for each…
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.
Place pre-flight checks at the prep/execution boundary…
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.
If you check a box in under 5 seconds without pausing…
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.