PRACTICAL GUIDE · ARCHITECTURE GOVERNANCE
Consolidate custom architecture checks in a shared contract
AI-assisted development can leave a growing collection of custom drift, dependency and interface gates. A shared architecture contract gives architects and coding agents one place to review supported structural rules.
Start with one rule
Inventory each existing check: its owner, scope, inputs, expected failures and what happens when evidence is missing. Select one overlapping dependency or public-interface rule. Express the intended boundary in ArchKeel and run both checks side by side.
For a concrete example, the public Shop fixture declares that shop.render must not depend on shop.store. Its DEP-RENDER-NO-STORE rule reports the source location of a forbidden import. Reproduce the finding and baseline check.
Prove equivalence before removing a gate
- Verify an allowed case passes in both checks.
- Introduce a representative forbidden change and confirm both reject it.
- Remove or obscure required evidence and check that neither silently reports success.
- Compare scanned paths, languages, exceptions and CI exit behavior. Review differences with the owner.
Only retire the old check for the scope that has actually been matched. The Shop example demonstrates a boundary check; it does not establish parity with any particular project-specific gate.
Keep checks that answer different questions
An architecture contract does not prove runtime behavior, backward-compatible API responses, security properties or data integrity. Keep the tests that cover those. SPOT ownership can be declared and repeated logic can be flagged for review; neither automatically proves that all duplicated knowledge has been found.
See what we observed in DATAMIMIC CE and EE, including unresolved evidence and a runtime boundary that required a separate test.