The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
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.
When a workflow produces inconsistent outputs despite consistent effort, diagnose missing or unstable input-output specifications before attempting to fix the process itself.
Structure handoff communications using the SBAR protocol (Situation, Background, Assessment, Recommendation) when transferring responsibility for work between people or contexts.
Collect at least five measurements of a workflow before attempting to improve it, to distinguish common-cause variation (inherent system fluctuation) from special-cause variation (identifiable disruptions).
Track workflow quality using multiple metrics that create tension with each other—at minimum cycle time, error rate, and energy cost—to prevent optimization of any single metric from corrupting the system.
After each workflow execution, identify exactly one improvement to implement before the next execution—not zero, not three—to enable attribution of changes to effects.
Give each workflow change at least three to five executions before deciding whether to keep, modify, or revert it, to distinguish persistent effects from noise and prevent oscillation.
Design workflow variants as complete self-contained strategies for specific contexts rather than as degraded versions of a single 'ideal' workflow, with each variant having its own integrity and appropriate output standards.