Why the Naked Arrow Is the Most Dangerous Glyph in Diagramming
Draw a plain arrow from component A to component B and you have said almost nothing — yet every reader will confidently believe it said something specific. One sees data flowing, another sees a startup dependency, a third sees an event trigger, a fourth sees a sequencing rule. The same stroke supports four incompatible interpretations, and the diagram offers no way to arbitrate between them.
This is not a theoretical problem. Post-mortems repeatedly trace integration defects to edges that meant "depends on" to the author but "sends data to" to the implementer. The fix is not more arrows — it is committing each arrow to exactly one semantic family and marking that commitment visually.
Core Diagnostic Rule: Every Edge Needs a Declared Semantic Family
Before drawing a connector, answer: does something move (flow), must something exist first (dependency), does something awaken (trigger), or must something come earlier (sequence)? Then style and label the edge accordingly.
Unadorned arrows persist because they are cheap — they defer the hard question of what the relationship actually is. But the cost is paid later, by every reader who must reverse-engineer intent, and by every engineer who implements the wrong integration semantics.