Sequential-by-default is a workflow smell — every numbered list should be questioned for which steps actually depend on which

Why This Is a Rule

Numbered lists are the default notation for workflows, and numbered lists imply sequence. This creates a systematic bias: documentation format imposes false serialization on inherently parallel work. When you write "1. Do A. 2. Do B. 3. Do C," you've implied A→B→C even if A, B, and C are completely independent. Every reader — including your future self — will execute them in order because the format says "order matters."

This is a "code smell" analog for workflows. In software, a code smell doesn't guarantee a problem but signals that investigation is warranted. Similarly, a fully sequential workflow doesn't guarantee false serialization, but it's statistically unlikely that every step truly depends on the previous one. Most real workflows are partially parallel, and the sequential representation hides the parallelism.

The cost of false serialization is significant for complex workflows. If a 10-step workflow has 5 truly sequential steps and 5 parallelizable ones, the serial representation takes 10 time units while the parallel-aware representation takes 5-7. Over hundreds of workflow executions, the accumulated waste from unquestioned sequentiality is enormous.

When This Fires

• When reviewing any existing numbered-list workflow for optimization opportunities
• When you notice a workflow taking longer than expected despite each step being efficient
• When creating a new workflow and writing it as a numbered list — pause and test for parallelism
• Complements Dependency test for adjacent steps — does step B require the completed output of step A? If not, they can run in parallel (pairwise dependency test) with the meta-level awareness that serial is the default bias

Common Failure Mode

Accepting numbered order as dependency order without question. "The workflow says step 2 comes after step 1, so I'll wait for step 1 to finish before starting step 2." But the numbering may reflect the order the author thought of the steps, not their actual dependencies. The cost of questioning is a minute of analysis; the cost of not questioning is repeated unnecessary waiting.

The Protocol

(1) When you encounter or create a numbered-list workflow, treat the serial format as a smell, not a specification. (2) Apply Dependency test for adjacent steps — does step B require the completed output of step A? If not, they can run in parallel's dependency test to every adjacent pair: "Does step N+1 actually need step N's output?" (3) Regroup: put truly independent steps into parallel buckets. Notation: "Phase 1: [A, B, C in parallel]. Phase 2 (after A completes): [D]. Phase 3 (after B and D complete): [E, F in parallel]." (4) For workflows you execute regularly, the one-time cost of dependency analysis pays for itself within a few executions through time savings. (5) Make parallelism visible in the notation: side-by-side columns, "concurrent" labels, or dependency arrows rather than numbered lists.