Map actual information flow to distinguish artificial serialization from premature parallelization — assumed ordering is often wrong

Why This Is a Rule

Two opposite scheduling errors produce different failures. Artificial serialization treats independent tasks as if they were dependent, forcing sequential execution when parallel execution would be safe and faster. "I can't start the presentation until the data analysis is complete" — but maybe the presentation structure and the data analysis are independent, and only the final integration of data into slides requires the analysis to be done. Premature parallelization launches tasks before their dependencies resolve, producing rework when the dependency's output invalidates work already done. "I'll start coding while requirements are still being finalized" — then requirements change, and the code needs rewriting.

The diagnostic is information flow mapping: for each pair of tasks, ask "does task B actually consume specific output from task A?" If yes → the dependency is real; serialize. If no → the dependency is artificial; parallelize. "Does B consume A's output?" is more precise than "does B come after A?" — many tasks that habitually follow each other don't actually depend on each other's outputs.

When This Fires

• When optimizing workflow execution order
• When a workflow feels slow despite having "enough time" — artificial serialization may be hiding parallelizable steps
• When parallelized work keeps requiring rework — premature parallelization may be launching steps too early
• Complements Parallelize independent agents, serialize only true dependencies — don't wait for steps that don't need each other's output (parallelize independent agents) with the diagnostic for distinguishing real from artificial dependencies

Common Failure Mode

Using habitual order as evidence of dependency: "We always do research before writing, so writing depends on research." Does writing consume the research output? If you're writing an introduction that doesn't reference the research findings, the intro writing doesn't depend on research — it's artificially serialized. The findings-integration section does depend on research — that dependency is real. Mapping actual information flow reveals that "research before writing" is partially artificial serialization.

The Protocol

(1) List all tasks in the workflow. (2) For each pair where A currently precedes B, ask: "Does B consume specific output from A? What exactly does B need from A?" (3) If B consumes A's output → real dependency. Serialize. (4) If B doesn't consume A's output → artificial serialization. These tasks can run in parallel. (5) For tasks you want to parallelize, verify: is A's output genuinely unnecessary for B, or is it needed at some sub-step? If only a sub-step of B needs A's output → partial parallelization: start B, run in parallel until the dependent sub-step, then synchronize. (6) After remapping, verify: are any parallelized tasks now failing because they actually did need upstream output? If yes → you've identified a premature parallelization. Re-serialize that specific pair.