How can architectural standards be enforced automatically, and which standards genuinely cannot be?

What can be checked automatically

More than most organisations attempt:

• Module and layer dependency rules, failing the build on a forbidden import — the mechanism that decides whether architectural boundaries hold for years or for months.
• Infrastructure policy: encryption at rest, no public storage, required tags, approved regions, network rules — evaluated at deployment and continuously against actual state.
• Ownership metadata present on every service, so an unowned service in production is impossible rather than merely undesirable.
• Observability instrumentation: standard metrics, structured logs with correlation, trace context propagation. One service dropping trace context breaks every trace passing through it, which makes this a collective property worth enforcing.
• Provenance and supply chain: artefact signed by the expected builder from the expected source.
• API compatibility: no breaking changes to a published contract, verified against every consumer.
• Schema change safety, blocking destructive changes outside expand-contract.
• Approved technology use, checked against the paved-road list at provisioning.
• Fitness functions for measurable architectural qualities: response time budgets, dependency count limits, bundle size, query counts per request.

The pattern: anything expressible as a property of an artefact or a configuration can be checked, and the list is longer than the standards most organisations write down.

What cannot be checked automatically

• Whether the boundaries are in the right place. A rule enforces the declared structure; it cannot tell you the structure is wrong.
• Whether the design fits the problem, or whether a simpler one would serve.
• Whether the trade-offs were understood and the alternatives considered.
• Semantic correctness — a service satisfying every structural rule while doing the wrong thing.
• Whether the complexity is justified, which is a judgement about the future.
• Operability: whether a human can understand and run it at 3am.

These require review, and confining review to them is what makes review valuable — a session spent on whether the boundaries are right is worth far more than one spent on whether the tags are present, and the automation is what frees it.

Making automated checks work

• Start by asserting the current state, then tighten. A rule set that fails on day one is disabled on day one.
• Fail fast, in the pull request, where the feedback is actionable — not in a nightly report.
• A documented exception path with a named approver and an expiry, because a rule with no exception path is deleted the first time it is genuinely wrong, and a visible exception is far better than an invisible workaround.
• Track the override rate, which is the honest signal: a rule overridden routinely should be fixed or demoted to a warning.
• Prefer generated compliance to checked compliance. A golden path producing the correct configuration removes the need for the check — a platform relying mainly on gates has made the wrong thing difficult rather than the right thing easy, which is felt as bureaucracy.
• Own and evolve the rules deliberately, since an architecture that changes needs its rules to change with it, and stale rules block legitimate work and lose credibility.