How dependencies propagate

Dependency propagation is the mechanic by which changes to one node ripple through the graph to affect every downstream node. When a node's status changes, every node that depends on it (directly or transitively) re-evaluates its own status.

The three rules

The propagation follows three rules.

1. When a node completes, its direct dependents check whether all their prerequisites are now complete. If yes, they unlock (move from locked to available). If no, they stay locked until their remaining prerequisites also complete.
2. When a node is added to the graph with an edge pointing to an existing node, the existing node's status re-evaluates. If the new node is a prerequisite and isn't complete, the existing node moves from available to locked. If the new node is complete, no change.
3. When a node is removed from the graph, every node that depended on it re-evaluates. If the removed node was the only locked prerequisite, the dependents unlock. If other prerequisites remain incomplete, the dependents stay locked.

Automatic and continuous

Propagation is automatic and continuous. The team doesn't trigger it manually. The graph evaluates the implications of every change as it happens.

Bounded depth

Propagation has bounded depth. The mechanic only re-evaluates nodes whose ancestry includes the changed node. Unrelated parts of the graph are unaffected.

This keeps propagation cheap even on large projects: a status change in one branch doesn't trigger evaluation of distant branches.

Why this matters

The mechanic is what makes the graph "alive." Without propagation, the structure would be a static diagram. With propagation, the structure is a continuously evaluated model of what the team can work on right now.

Mark a node complete, watch the next tier unlock, see what becomes available. This is the loop the product is built around.

Related

• Edge
• How unlocking works
• How branching works
• How completion cascades