Structural Reliance vs. Procedural Progression
In complex architecture models and workflow specifications, an arrow between two entities frequently serves double duty. Engineers often draw an arrow to indicate that component A requires component B to function, while simultaneously implying that execution moves from A to B. This visual overlap creates fundamental misunderstanding across engineering, product, and infrastructure teams.
A dependency connection expresses a structural constraint or reliance rather than an active movement of bytes or execution control. When system A depends on library B, system A cannot compile or operate reliably without B existing in a valid state. Nothing travels across the boundary at runtime during simple reliance; rather, the existence and stability of the prerequisite govern the behavior of the reliant entity.
The Dependency Semantic Rule
If Component A cannot fulfill its contract without Component B, the relationship is a dependency. Reversing the arrow to denote "data return" or "runtime call" without explicit labeling confuses architectural hierarchy with runtime protocol.
When diagram authors fail to differentiate dependencies from runtime flows, observers interpret structural prerequisites as downstream workflow steps. This results in deployment pipeline errors, circular dependency deadlocks, and missed failure domain boundaries.