Documentation Dependency Model

Summary

Dependencies connect a page to the upstream artifacts it relies on and the downstream documentation or product nodes affected by change.

Documentation maintainers, developers, QA engineers, architects, product owners, and operations teams

Node type	Typical upstream dependencies	Typical affected documentation
Module	Identity, tenant, organization, shared capabilities	Overview, business, technical, operations
Service	Contracts, configuration, data ownership, gateway	Architecture, API, runbooks, troubleshooting
API	Service behavior, authorization, domain validation	How-to, reference, UI integrations
Event	Producer state change, contract version	Consumer docs, projections, notifications
Database	Aggregate ownership, retention, migrations	Technical, operations, migration guidance
UI	API contracts, roles, feature access	UI guides, tutorials, troubleshooting
Business Process	Modules, actors, states, policies	Concept, how-to, UI, reporting
Reference	Source contracts and controlled vocabularies	Search, automation, other references
Troubleshooting	API errors, events, dependencies, operations	Runbooks, support and escalation
Architecture	Services, boundaries, decisions, deployments	All implementation-facing documentation

Use depends_on only for a necessary upstream relationship.
Use used_by for verified downstream consumers, not possible consumers.
Use typed related_* fields for discovery without implying runtime dependency.
Store stable identifiers rather than display labels where a registry exists.
Record evidence in source_of_truth or a linked approved architecture decision.
Update or remove edges when implementation status becomes legacy, deprecated, or removed.
A dependency change triggers review of the node and its transitive used_by pages according to risk.