The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
Place materials for the next behavior at the physical location where the current behavior completes to reduce transition friction and support automatic chaining.
Cut recurring low-stakes decision domains to 3-7 options maximum, because this range matches working memory capacity for effective comparison without overload.
Apply choice reduction to routine, low-stakes, high-frequency decisions where options are hard to compare, but maintain full optionality for novel, high-stakes, infrequent decisions with clear evaluation criteria.
Implement one-in-one-out constraints where adding a new option requires removing an existing one, preventing option accumulation from eroding reduction benefits over time.
Treat pre-decisions as defaults that activate automatically unless new information justifies override, distinguishing genuine context changes from familiar resistance wearing the costume of novelty.
Limit pre-decision scope to meaningful activity levels—what to eat, work on, when to exercise—not to fifteen-minute blocks, to avoid replacing decision fatigue with compliance fatigue.
Design defaults for your actual self under realistic conditions, not for your ideal self under optimal conditions, because defaults must hold when capacity is low not just when motivation is high.
Mark decision points in documented workflows with explicit notation (like decision diamonds) that states 'If X, then step Y; otherwise step Z' to make conditional logic visible.
For each workflow step, apply the competent stranger test: if you handed this step to a competent stranger with no additional context, could they complete it without asking a single clarifying question? Any step that fails this test is not yet atomic.
Test workflow step granularity with the failure localization criterion: if this step fails, will I know what went wrong without further investigation? If no, the step needs further decomposition.
When documenting workflows for handoff or future self, use finer granularity than workflows written for immediate personal use, calibrating the competent stranger to match the least experienced actual executor.
For each pair of adjacent workflow steps, ask 'Does step B require the completed output of step A?' - if no, the steps can run in parallel; if yes, they must be sequential.
When mapping workflow dependencies, draw arrows for both input-output dependencies and resource dependencies (shared attention, tools, or collaborators), since steps sharing scarce resources are effectively sequential even if outputs are unrelated.
Treat 'sequential by default' as a workflow smell requiring dependency analysis - every numbered list should be questioned for which steps actually depend on which.
Position triggers at transition moments between contexts rather than within stable contexts, as transitions are perceptually distinct and represent natural decision points.
Define workflow completion criteria as binary observables ('draft exists') rather than subjective evaluations ('draft is good') to create clear termination points that prevent recursive perfectionism.
Before optimizing any workflow step, measure actual elapsed time across three to four execution cycles rather than relying on felt difficulty or estimated duration, because subjective experience systematically misidentifies bottlenecks.
Direct optimization effort exclusively at the single slowest step in a workflow, treating all improvements to non-bottleneck steps as wasted effort regardless of their magnitude.
When a workflow bottleneck is a waiting step rather than a processing step, reduce work-in-progress before attempting to speed up any active processing, because Little's Law dictates that cycle time equals WIP divided by throughput.
Classify workflow steps as 'automate now' (well-defined, no judgment, high frequency), 'automate later' (well-defined, no judgment, low frequency), 'assist' (requires judgment but tools handle mechanical portions), or 'keep manual' (requires judgment, taste, or values only you provide).
Before automating any step, apply the sovereignty check by asking 'if this automation produces wrong output, will I notice?' — automate only when the answer is yes through review, downstream dependencies, or verification checkpoints.
Periodically perform automated steps manually as calibration exercises to maintain intervention skill and detect when automation has drifted or is producing incorrect outputs.
Define workflow inputs as complete checklists of preconditions—every piece of information, material, and state that must be true before the first step can execute—rather than treating inputs as obvious or self-evident.
Make workflow output specifications operational by defining them as Definitions of Done with explicit, checkable acceptance criteria rather than vague quality aspirations.