Causal sequencing
Causal sequencing is the order steps have to happen in because of how the end result is actually produced, not because someone picked that order. If a diagram puts the steps in a different order than causation requires, following the diagram breaks the result.
Definition
Relations among sub-conditions on the critical route that govern the order in which their sub-transitions can be performed.
Order inherited from causation
Sub-transitions on the critical route are not freely orderable. Some sub-conditions must be established before others: the later sub-transition consumes or builds on what the earlier one produces, and the dependency is structural. Other sub-conditions are independent of each other (see sibling independence) and can be performed in any order, or in parallel.
The order is set by how the completion criteria are caused. Whether one sub-transition needs another's output is determined by the resulting state the parent transition is producing; the designer doesn't choose it.
Two kinds of sequence
Two different things often get conflated:
- Diagram sequence — the order sub-transitions appear in when written down or drawn. A human-legibility convention; useful for storytelling and inspection.
- Causal sequence — the order sub-transitions actually have to occur in for the parent transition to succeed. Inherited from causation.
The two usually align: a well-specified diagram places sub-transitions in an order that respects their structural dependencies, because that's the order the story reads coherently in. When they diverge, the causal sequence governs and violations produce transition failure.
Diagnosing specification gaps
The way sub-transitions read in order is diagnostic of whether the underlying specification is complete. When the story doesn't cohere — when the sequence reads as if one step requires something the prior step doesn't produce — that's a prompt to return to the specification and check. Two cases produce narrative incoherence:
- Unstated dependency — the sequence implies a causal step the specification doesn't carry. The specification is incomplete; declare what the later step requires from the earlier one.
- Violated dependency — the specification is correct, but the sequence places sub-transitions in an order that breaks a dependency it carries. Reorder.
Both resolve at the specification layer, not by editing the sequence in isolation.
Example
In a CRM, sending a first email campaign requires contacts to exist in the system. The campaign sub-transition takes a recipient list as input; the import-contacts sub-transition is what produces that list. A team that designs the onboarding flow as "send first campaign → import contacts" has written down a sequence that can't execute — the campaign step has no list to draw from.
The same shape holds in analytics tools (connect data source → build dashboard) and project management tools (create project → assign task). Whichever step consumes another's output has to come after it. Diagram sequence has to follow causal sequence.