Machine-Checkable Standard

An organisation of 120 teams shipping several hundred changes a day cannot govern by review. A board seeing 20 designs a week covers under 1.5% of changes, and it does not choose which 1.5%: the submitters do. Adding architects doubles a number that would need a hundredfold increase.

The alternative is not "less governance". It is writing the subset of rules that a machine can decide, running them in every pipeline, and using the human forum for the rules a machine cannot decide. The split is not between important and unimportant rules — it is between rules that are unambiguous and rules that require judgement, and both kinds are important.

Why it matters

Timing changes obedience more than authority does. A rule enforced at merge time, with a message saying what to fix, is a design input: the engineer encounters it while the change is still in their head, and complying costs minutes. The identical rule enforced by a review six weeks later is rework, and rework generates the negotiation, exceptions and resentment that give architecture governance its reputation.

The second effect is on the forum. When the mechanical checks run themselves, the review board stops spending its time on tagging conventions and base images and starts spending it on whether a service boundary is in the right place — the work it is uniquely able to do and currently cannot reach through the queue.

Implementation patterns

• Start with five rules, not fifty. Each must be unambiguous, consequential, and traceable to a real incident or obligation. The usual first five: every service declares an owner and an on-call route; no internet-facing endpoint without TLS and authentication; container images from approved bases; no credential outside the secret store; infrastructure carries cost-attribution tags.
• Run at the cheapest binding point. A pull-request check for source-level rules; an admission controller or deploy gate for runtime properties, because source checks can be bypassed by anything that does not go through the repository.
• Write the failure message as an instruction. "Add owner: to service.yaml; see " not "policy OWN-002 violated". The message is the documentation that anybody actually reads.
• Exemptions are first-class: requested in code, granted with an expiry date, visible in a report. A rule with no exemption path is routed around, and then you lose both the compliance and the knowledge that it was not met.
• Publish coverage, not just compliance. What fraction of the estate the check can even see matters more than the pass rate among those it sees.
• Retire rules. A standard set that only grows becomes a tax; review it annually and delete the rules that have not failed usefully.

Industry example

The open-source policy engines that made this mainstream — Open Policy Agent, donated to the CNCF in 2018 and graduated in 2021, with its Kubernetes admission-control and test tooling — are the visible infrastructure of the idea, and the pattern predates them in the form of lint rules and build-time checks. The instructive part of the public adoption accounts is consistent: teams that started with a handful of rules and good messages succeeded, and teams that ported an entire standards document into policy produced a pipeline nobody could pass and an exemption list longer than the ruleset.

Failure scenarios

• Fifty rules on day one, so every build fails for reasons unrelated to the change and the checks are switched to warning-only within a month.
• No exemption path, so a team with a legitimate reason either lies on a form or moves their workload somewhere the check does not run.
• Checks that see only part of the estate, giving a 98% pass rate over the 40% of systems that go through the standard pipeline — an accurate number and a false impression.
• Rules encoding preference rather than consequence (a naming convention, a preferred framework), which trains engineers that the checks are arbitrary and undermines the ones that matter.
• A stale ruleset that enforces a decision reversed two years ago, which is how policy engines become the thing that prevents improvement.
• Policy as the only governance, so nobody is asking whether a service should exist at all.

Trade-offs

The cost that surprises people is ownership. A policy set is software: it has bugs, it needs tests, and a false positive blocks every team at once. Budget for it accordingly, and treat a broken check as an incident.

When not to use it

Below roughly a few changes a day, a human review triggered by significance is cheaper and better, and the automation is pure overhead. It is also the wrong tool where the problems are design-shaped rather than rule-shaped — if the estate's trouble is that boundaries do not match the work, no check can decide that, and encoding rules will produce compliance alongside the same architecture.

The strongest alternative to both is to make the check unnecessary: if every service is created from a paved-road template that already sets the owner, the base image, the secret store and the tags, the rule is satisfied by construction, and the check becomes a safety net rather than a gate. Prefer that where a single path exists; fall back to checks where it does not.

Interview question

Q: You have 120 teams, several hundred changes a day, a wiki of standards that is inconsistently followed, and funding for one governance investment. Design what you would build in the first quarter, and tell me how you would know a year later whether it worked.

What a strong answer covers: the arithmetic ruling out review as the primary mechanism; five rules chosen for being unambiguous and consequential, each traceable to an incident; enforcement at the cheapest binding point with instructional failure messages; a logged, expiring exemption path from day one; coverage reported alongside compliance; and, for the year-later question, that success shows up as change failure rate falling without lead time rising, not as the compliance percentage — the percentage is what the practice produced, not what it achieved.

Quick check

Quiz: Why does moving a rule from a review board to a pipeline check change adherence more than adding authority does? — Because the pipeline enforces it while the change is still being made, when complying costs minutes; the same rule six weeks later is rework, which is what generates negotiation and exemptions.

Flashcard: What must every machine-checked architecture rule carry? — A documented reason, a failure message written as an instruction, and a logged exemption path with an expiry date; without the exemption path the rule is routed around and you lose the signal as well as the compliance.