Search docs
Docs searchDependency Validation
Dependency Rules & Module Contracts
ArchPilot validates cross-module dependencies, public entrypoints, module contracts, and architecture boundaries so dependency drift becomes visible early.
Use dependency rules and module contracts when you want architecture policy enforcement that is specific enough to catch boundary drift, but still practical enough for everyday engineering work.
What ArchPilot checks
- Forbidden cross-module dependencies
- Direct imports that bypass a module’s public entrypoint
- Missing or unused declared dependencies
- Circular dependencies that create architecture risk
- Layer-direction violations where teams model layered architecture
Dependency evidence coverage
Dependency findings depend on both the governed architecture model and the dependency evidence ArchPilot can establish from the repository.
When dependency analysis is Established, ArchPilot has enough reliable relationship evidence to evaluate dependency contracts meaningfully. When it is Partial or Not established, ArchPilot surfaces the coverage state conservatively instead of presenting an incomplete graph as complete.
Partial and Not established are capability states. They do not mean the architecture is partially compliant, clean, or dependency-free.
Why module contracts matter
Module contracts make boundaries explicit. Instead of treating architecture as a convention that developers must memorize, ArchPilot gives teams a local source of truth for which modules can depend on which other modules.
That is especially useful for architecture as code, dependency validation, and architecture policy enforcement in larger repositories.
How teams usually adopt this
- Start with the repository’s natural module structure.
- Generate or refine module contracts so the intended boundaries are explicit.
- Run validation to see boundary violations and public entrypoint issues.
- Tighten rules gradually as the architecture model becomes more accurate.