The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
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.
Restart operations sequentially after disruption by adding tier 1 first, confirming stability, then adding tier 2, then tier 3, rather than attempting simultaneous restart of all habits.
Add a single recurring check at the end of each weekly review that compares your operational handbook to your actual operations and updates discrepancies immediately.
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.
When receiving critical feedback, insert a physical pause (close laptop, stand up, or wait 90 seconds) before responding to allow prefrontal cortex engagement rather than amygdala-driven reaction.
After any operational failure, write a blameless post-mortem using five questions: what happened (factual description), what was the timeline of contributing events, what were the systemic factors, what are the action items (specific system changes), and what would have prevented this.
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.
In emotionally charged messages, draft your reactive response first in a private document, then wait 10 minutes before composing the actual message, using the comparison between versions as data about emotional distortion.
When using AI to draft difficult communications, compare your reactive draft against the AI-generated neutral version to measure where emotions are distorting your message, rather than sending the AI version directly.
Replace evaluative words that smuggle judgment ('interrupted,' 'ignored,' 'slammed') with camera-observable behavior descriptions ('began speaking while I was mid-sentence,' 'has not replied since Tuesday') in feedback conversations.
In technical postmortems, use 'how' questions ('how did the deployment occur') rather than 'why' questions ('why did you skip review') because 'how' elicits description while 'why' elicits defensive justification.
Before high-stakes observations (meetings, decisions, analyses), write down your current mood and strongest expectation about the outcome to make perceptual filters visible for later comparison against actual observations.
When debugging with strong initial hypotheses about root cause, deliberately search logs for evidence that would falsify the hypothesis rather than confirm it, to counteract confirmation bias in data collection.
During incident response, enforce a mandatory 5-minute observation period where team members only report dashboard data and log patterns before anyone proposes a causal theory.
After initial defensive emotional reaction to feedback, name the specific emotion with high granularity ('I notice frustration about the timeline comment, not the technical critique') before responding, to activate prefrontal regulation.
When using implementation intentions to create behavioral pauses, specify the triggering situation at high detail ('If I receive code review feedback challenging my approach...') rather than generically ('If I get criticism...') to increase cue detectability.