Contracts

ArchLinterNet contracts define executable architecture rules.

Most contract families have two variants:

• strict — blocking rules for the current architecture gate;
• audit — diagnostic rules for migration discovery and future-state visibility.

Contract family map

Family	Strict group	Audit group	Use when
Dependency	strict	audit	A source layer must not reference forbidden layers.
Layer order	strict_layers	audit_layers	Dependencies must point inward through an ordered layer stack.
Allow-only	strict_allow_only	audit_allow_only	A source layer may reference only explicitly allowed layers.
Cycle	strict_cycles	audit_cycles	Selected layers must not form directed dependency cycles.
Acyclic sibling	strict_acyclic_siblings	audit_acyclic_siblings	Direct sibling namespaces under an ancestor must remain acyclic.
Independence	strict_independence	audit_independence	A set of modules/layers must not reference each other.
Assembly independence	strict_assembly_independence	audit_assembly_independence	A set of compiled .NET assemblies must not directly reference each other.
Assembly dependency	strict_assembly_dependency	audit_assembly_dependency	A source assembly must not directly reference forbidden assemblies.
Assembly allow-only	strict_assembly_allow_only	audit_assembly_allow_only	A source assembly may only directly reference explicitly allowed assemblies.
Project metadata	strict_project_metadata	audit_project_metadata	Selected discovered projects must preserve required metadata, restrict friend assemblies, and avoid forbidden project references.
Protected surface	strict_protected	audit_protected	A target layer may only be imported by approved layers.
External dependency	strict_external	audit_external	Source code must not leak forbidden vendor/framework dependencies.
External allow-only	strict_external_allow_only	audit_external_allow_only	A source layer may reference only explicitly allowed vendor/framework dependency groups.
Method body	strict_method_body	audit_method_body	Source code must not call forbidden APIs inside executable bodies.
Unity asmdef	strict_asmdef	audit_asmdef	Unity assembly definition references must follow architecture rules.
Layer template	strict_layer_templates	audit_layer_templates	The same ordered layer shape applies to multiple namespace containers.
Type placement	strict_type_placement	audit_type_placement	An architectural role must live in a declared layer/namespace/project/assembly and/or carry a declared naming suffix/prefix.
Public API surface	strict_public_api_surface	audit_public_api_surface	An assembly's exported public/protected types and members must match a declared allowlist.
Attribute usage	strict_attribute_usage	audit_attribute_usage	A declared attribute/marker type must (or must not) appear in a declared layer/namespace/project/assembly.
Inheritance	strict_inheritance	audit_inheritance	Types in a declared source layer/namespace must not inherit (directly or transitively) from declared base types.
Interface implementation	strict_interface_implementation	audit_interface_implementation	Implementations of declared interfaces must reside only in (or never in) declared layers/namespaces/projects/assemblies.
Composition	strict_composition	audit_composition	Composition-root/service-locator API calls must be confined to a declared composition boundary.
Coverage contracts	strict_coverage	audit_coverage	First-party namespaces, discovered projects, and resolved assemblies must be modeled by layers, templates, or explicit exclusions.

Strict or audit?

Use strict contracts for rules that should be green on every pull request.

Use audit contracts when you are discovering existing coupling, preparing a future architecture, or migrating an existing codebase. Audit output should be visible, but it should not be confused with a passing architecture gate.

Contract identity

Add an explicit id when a contract will be referenced by CI, baseline files, documentation, or issue discussions:

contracts:
  strict:
    - id: domain-not-infrastructure
      name: domain-must-not-depend-on-infrastructure
      source: domain
      forbidden: [infrastructure]
      reason: Domain code must remain independent of infrastructure.

When id is omitted, ArchLinterNet derives one from name, but explicit IDs are more stable for long-lived policies.

Unsupported rule types

Do not invent YAML fields or contract families. ArchLinterNet validates only the contract families documented in this section and in the YAML schema.

See Supported capabilities and non-goals before adding new policy concepts.