Unenforced Standard
also called Paper Standard, Decorative Governance
A written rule with no mechanism behind it - an anti-pattern whose cost is paid per decision in argument and divergence work while compliance stays partial and uniformity is never achieved.
A standard says every new service must emit structured logs with eight required fields. Twenty-six teams ship roughly 30 new services a year and about 45% comply. Nobody is defying anyone; the standard has no mechanism, so compliance competes with each team's own deadlines and loses more often than it wins.
It persists because the cost is invisible in any single quarter. A standard's cost is paid per decision; a mechanism's is paid once.
Why it matters
For the numbers above: argument time at 30 services × roughly 2 hours is about 60 hours a year. Divergence work for the 16 non-compliant services — bespoke parsing, dashboard wiring, alert rules — at roughly 6 hours each is about 100 hours. One multi-service incident running 90 minutes long with 6 engineers adds about 9 hours. Roughly 170 engineer-hours a year, $17k to $25k at 2026 rates, recurring, for no uniformity at all.
A template with the fields wired in costs about 80 hours once plus roughly 32 hours a year of maintenance, and takes the inflow to near-total compliance because compliance becomes the path of least resistance. Payback lands inside the first year.
The deeper cost is to the architect. Every unenforced standard teaches the organisation that architectural statements are optional, spending the credibility the few load-bearing decisions depend on.
Implementation patterns
The fix is to pick a rung on the enforcement ladder and be honest about which one you are on.
| Rung | Mechanism | Cost | Coverage |
|---|---|---|---|
| Recommendation | A document and an example | Hours | Whoever reads it |
| Default implementation | Template or library with it wired in | ~80 hours once | New work, near-total |
| Mechanical check | CI rule that fails the build | 1 to 3 weeks | New and drifted work |
| Platform default | The only sanctioned path provides it | Months | Everything on it |
- Write a standard only when you can name the mechanism that will carry it. If you cannot, publish a default implementation and call it a recommendation, which is honest and costs nothing to not enforce.
- Give every mechanical control an escape hatch with a named approver, or teams fork the template and you lose the visibility you wanted.
- Close the inflow before retrofitting the backlog, or the debt rebuilds at the rate of new work.
Industry example
Atlassian's April 2022 incident shows which rung a human-carried standard sits on. The rule was that destructive maintenance scripts get peer reviewed, and the review happened as specified: its post-incident review records that it covered which endpoint was called and how, while the deletion API accepted both site and app identifiers and assumed the input was correct. 883 sites for 775 customers were deleted in 23 minutes. Read it as an enforcement-rung problem rather than a review-quality one: the standard rested on a human noticing a property of the data, which is the recommendation rung wearing the clothes of a control. The mechanical rung is an API that requires the caller to declare the object type and the expected count.
Failure scenarios
- Governance by review board: 30 design reviews a year at roughly 3 hours each is 90 hours, it queues every team behind the architecture group, and violations surface after the service already emits the wrong logs.
- Governance by communication: republishing the standard, when 45% compliance among teams who all read it is an effort problem rather than an awareness problem.
Trade-offs
Mechanical enforcement buys uniformity and takes the per-decision argument to zero. It pays in build time, in friction when a legitimate exception fails the build, and in a template someone must own. A standard with no mechanism costs almost nothing to produce, which is why organisations have dozens, and its bill arrives as recurring engineer-hours no budget line attributes to it.
When not to use it
With 3 teams and 4 new services a year, 80 hours of template work against 8 hours of annual argument is over-engineering: a documented example and a conversation is the answer, and the unenforced standard is fine because the inflow is small enough for social enforcement. The same holds where the rule admits many correct answers, since mechanising a judgement call gives either a check so loose it means nothing or one that blocks reasonable designs. Mechanise constraints, recommend judgements.
Interview question
Q: "You inherit twelve written architecture standards and no enforcement. You have one engineer-quarter. What do you do, and what do you tell the teams?"
What a strong answer covers: pricing each standard by inflow volume and divergence cost rather than importance; building a default implementation for the two or three with the highest per-decision cost; demoting the rest to recommendations in public, which is the credibility-preserving move; and closing the inflow before funding any retrofit.
Quick check
Quiz: Why does an unenforced standard cost more than no standard? Its bill is paid per decision in argument and divergence work, every year, for no uniformity — and it teaches the organisation that architectural statements are optional.
Flashcard: What is the rule for writing a standard? Write one only when you can name the mechanism that will carry it — template, CI check or platform default; otherwise ship a default implementation and call it a recommendation.