The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
When your commitment-to-capacity ratio exceeds 0.85, respond to new requests with explicit counter-offers stating either a later start date or a specific trade-off rather than accepting or declining without alternatives.
Design capacity signals with neutral, operational framing (traffic light status, numerical availability) rather than emotional or complaint-based language, delivering them before requests arrive rather than as request-time justifications.
Create annual capacity maps rating each month 1-5 based on historical data, then distribute annual commitments proportionally to predicted monthly capacity rather than dividing by twelve uniformly.
Maintain a commitment-to-capacity ratio below 0.85 to accommodate variance, treating any ratio above 1.0 as mathematical proof that some commitments will fail regardless of willpower or prioritization.
When the same operational constraint appears in three consecutive weekly reviews, treat it as a structural issue requiring architectural change rather than tactical adjustment, escalating it from the weekly action item to a dedicated project.
When a deferred maintenance task's recovery cost exceeds its immediate execution cost by 3x or more, prioritize it above tasks with lower cost multiplication ratios.
Maintain an operational debt register that records what was deferred, when, why, and the estimated cost of continued deferral, reviewing it during weekly rhythms to distinguish strategic from accidental debt.
Follow the automation hierarchy of eliminate-simplify-automate in strict order, because automating waste entrenches it and automating complexity makes it brittle.
Automate only tasks where the rule can be stated completely (fixed rule, known inputs, predictable outputs) and execution requires no judgment about exceptions or novel cases.
Maintain an automation registry listing each automation's function, tool, last verification date, failure indicators, and review cadence to prevent automation debt accumulation.
Start automation at the lowest-tech level that solves the problem (checklists, templates, calendar events) before considering platforms or scripts, because simplicity reduces maintenance burden.
Rank operational habits into three tiers (minimum viable, performance-improving, optimizations) so you know which to preserve under moderate disruption (tiers 1-2) and severe disruption (tier 1 only).
After disruptions longer than two days, triage accumulated items (actionable + time-sensitive, resolved itself, archive) before chronological processing to eliminate waste from self-resolved issues.
Run operational systems at 70-85% of measured capacity to maintain adaptive buffer, because systems at full utilization cannot absorb environmental change without breaking.
Calculate maintenance budget for entire operational system (30 minutes to 2 hours weekly) as binding constraint; reject additional components when aggregate maintenance would exceed sustainable capacity.
Run one complete PDCA improvement iteration per week on a single operational system: state a hypothesis predicting how a specific change will improve a specific measurable outcome by an estimated amount, implement for one cycle, measure the result, then adopt, adjust, or abandon based on whether the prediction held.
When operational maintenance is scheduled at a time with no buffer, no reminder, and no fallback slot, add redundancy through a primary slot, backup slot, and automated reminder rather than increasing willpower.
For every operational task you currently frame as 'busywork,' write one sentence describing what would break if you stopped doing it for a month—if nothing breaks, eliminate it; if something breaks, relabel it as infrastructure.
When a keystone habit produces cascading benefits, protect its trigger conditions and structural enablers rather than optimizing the habit's internal execution.
Cross-reference your success pattern elements against your upcoming project plan before starting work, building in the overlapping conditions deliberately rather than hoping they emerge, as replication requires engineering.
When something arrives marked urgent, apply the two-hour test by asking what happens if you address it in two hours instead of immediately—if the answer is 'nothing changes,' defer it.
Create a three-tier source hierarchy—5-10 daily sources (Tier 1), 10-20 weekly sources (Tier 2), everything else checked only on specific need (Tier 3)—and review monthly, demoting sources that haven't changed your thinking.
Run a daily urgency log for one week, recording every urgent-feeling demand with timestamp, then scoring each on actual time-sensitivity and impact-if-delayed-two-hours to build calibration data on false urgency rates.
When scanning incoming messages with a defined goal, ask whether each item directly serves that goal—if yes process it, if no skip/archive/batch it—and do not evaluate whether it's 'interesting' or 'might be useful someday.'