Automated Governance
Encoding architectural rules as executable checks in the build pipeline, so conformance is verified continuously rather than reviewed periodically.
Architecture documents describe intent. Automated checks enforce it, and the difference is whether the system still matches the design a year later.
What can be checked mechanically, and usually is not: dependency direction (the domain layer must not import the persistence layer; service A must not call service B directly), layering violations, forbidden libraries or versions, API compatibility (diffing an OpenAPI or Protobuf schema for breaking changes), performance budgets, security policy (no public storage buckets, no unencrypted volumes), and licence compliance.
Why it outperforms review boards: it runs on every commit rather than at a checkpoint; it gives feedback in minutes to the person who caused the drift; it is objective, so there is no seniority contest; and it does not depend on a reviewer noticing.
Design guidance: start with a small number of rules that matter, since a pipeline that fails for trivial reasons gets bypassed. Each rule needs a clear message explaining why, or engineers work around it rather than complying. And there must be an exception mechanism with a record, so a legitimate deviation is documented rather than achieved by deleting the check.
The rules are then a living specification of the architecture — one that cannot silently go stale.