1.7 Engineering standards and exceptions

Overview and motivation

An engineering standard is a documented, agreed rule about how work is done. For example, “all services must expose a health-check endpoint,” or “all public web pages must meet WCAG (Web Content Accessibility Guidelines) 2.2 level AA.” A standard is not a suggestion, and not a mere convention. It is a commitment the organization holds itself to, ideally one you can check. This chapter is about the full lifecycle of standards, how a large organization authors, publishes, adopts, enforces, and evolves them, and, just as importantly, how it handles the cases that legitimately fall outside them through a governed exceptions process (also called a waiver process): a documented, time-boxed permission to deviate from a standard for a stated reason.

The motivation is that at scale, informal norms stop working. When five engineers share one room, “how we do things here” travels by conversation and osmosis. When five thousand engineers span dozens of teams, three time zones, and a decade of staff turnover, that tacit knowledge fragments into hundreds of incompatible local habits. Standards are how you write down your hard-won lessons once, so every team inherits them instead of relearning each one through its own outage. They reduce cognitive load, make code reviews about substance rather than style, let people move between teams, and give auditors and regulators something concrete to assess.

But standards carry a failure mode of their own: rigidity. A standard that admits no exceptions will, sooner or later, block legitimate work: a spike, a vendor constraint, a genuinely novel case the authors never imagined. Teams then either grind to a halt or, worse, quietly ignore the standard, which corrodes the credibility of every standard. The remedy is the old aphorism “the exception proves the rule.” A visible, principled exceptions process is what keeps standards both credible and humane. This chapter builds on decision-making and governance (chapter 1.5) and decision records (chapter 1.6), and feeds directly into coding standards and style (chapter 2.1), checklists (chapter 12.2), and templates (chapter 12.3).

Key principles

A standard states an outcome, and gives a reason. Rule plus rationale; without the why, people cannot judge when it truly applies.
If it can’t be checked, it isn’t a standard yet. Prefer testable statements over aspirations.
Standards are living documents. They are versioned, owned, dated, and revised, not carved in stone and abandoned.
Automate enforcement where you can; reserve human review for judgment. Machines check the mechanical; people check the meaningful.
Deviations are expected, not shameful, but they must be visible. An honest waiver beats silent non-compliance every time.
Time-box every exception. A permanent exception is a defect in the standard; surface it and fix the standard.
Words and examples over jargon and mandates. People follow standards they understand and can copy from.

Recommendations

Write standards that are clear, testable, and justified

A good standard is a short, self-contained document with a predictable shape so readers know where to look. Adopt one standard template (chapter 12.3) and use it everywhere. Essential sections include:

Title and identifier: a stable name and reference number for citation.
Status: draft, active, superseded, or retired, with a date.
The rule: stated as an outcome, plainly and unambiguously (“must,” “should,” “may,” used deliberately, per the RFC 2119 conventions for requirement keywords).
Rationale: why this rule exists; the cost or risk it prevents.
Examples: a compliant example and a non-compliant one; concrete beats abstract.
How it is checked: the automated test, linter rule, or review step that verifies it.
Owner and review date: who maintains it and when it is next revisited.

The rationale and the “how it is checked” fields are what separate a real standard from a wish. If you cannot say why a rule exists, question whether it should. If you cannot say how compliance is verified, the rule will be applied inconsistently and resented.

Pair each standard with a good-practice checklist

Standards define the destination. A good-practice checklist, a short, ordered list of concrete steps or items to confirm, helps people get there and lets them self-verify before review. Public-sector engineering handbooks use this pattern heavily. NHS Wales and Digital Health and Care Wales (DHCW) publish engineering standards with practical checklists, and the UK Government Digital Service (GDS) pairs its Service Standard and Technology Code of Practice with the Service Manual’s actionable guidance. The checklist is the standard made usable: “Have you added an accessibility audit? Have you tested with a screen reader? Have you covered keyboard-only navigation?” See chapter 12.2 for the checklist pattern in full.

Publish standards where people already work, and keep them discoverable

Store standards in version control (a source repository) as Markdown, rendered to a searchable internal site, so they get history, review through pull requests, and diffs for free, the same argument as for decision records (chapter 1.6). One catalog, one template, one search box. Surfacing matters as much as storage. Link the relevant standard from the pull-request template, the linter’s error message, and the service’s scaffolding, so the right rule appears at the moment of the work rather than in a folder no one visits.

Enforce through automation first, human review second

There are two ways to enforce a standard, and mature organizations use both deliberately:

Automated enforcement: linters, formatters, static analysis, policy-as-code (for example, Open Policy Agent (OPA)), continuous integration (CI) gates, and architecture fitness functions (automated tests that assert a design property still holds). Automation is consistent, tireless, immediate, and unarguable, which makes it ideal for the mechanical majority of standards (formatting, naming, dependency rules, required metadata).
Human review: code review, architecture review boards, and security review, reserved for what machines cannot judge: whether an abstraction is sound, whether a trade-off is wise, whether a standard’s intent is met even when its letter is awkward.

The rule of thumb: automate the checkable, and spend scarce human attention on judgment. Every standard you can move from review to CI frees reviewers to do the thinking only they can do.

Govern deviations with a documented exceptions/waiver process

No standard fits every case, so design the escape hatch on purpose. A good exceptions process specifies:

Who can grant a waiver: a named, accountable authority proportionate to the risk (a tech lead for a low-stakes style deviation; an architecture or security board for a security-control waiver). This ties directly to the governance model of chapter 1.5.
What must be recorded: the standard being deviated from, the specific reason, the scope, the compensating controls or mitigations, and the risk accepted. Capture this as a decision record (chapter 1.6) so the rationale is preserved.
A mandatory expiry: every waiver is time-boxed with an explicit end date. This is the single most important rule: it prevents a temporary exception from silently becoming permanent policy.
Periodic review: an owner reviews open waivers on a cadence and either renews them with fresh justification, closes them when the work complies, or, if the same exception keeps recurring, treats that as evidence the standard itself is wrong and revises it.

This last point is the heart of “the exception proves the rule.” A steady stream of waivers against one standard is not a failure of discipline. It is data. It tells you the standard is miscalibrated, and the fix is to evolve the standard, not to keep granting exceptions.

Treat standards as living documents with clear ownership

Give every standard an owner (a role, not just a person) accountable for keeping it current, and a review cadence (at least annually). Provide a lightweight path for anyone to propose a change through a pull request or an RFC (request for comments), a written proposal circulated for feedback before adoption. Version standards, deprecate them explicitly, and announce changes. A standards catalog that is never revised rots into folklore that people cite selectively and trust little.

Trade-offs: pros and cons

Choice	Pros	Cons
Many detailed standards	Consistency, easy onboarding, audit-ready	Rigidity; maintenance burden; can outpace practice
Few high-level standards	Flexible; low upkeep	Inconsistency; more re-litigation per team
Automated enforcement	Consistent, immediate, tireless, scalable	Upfront cost; false positives; blind to intent
Human review enforcement	Judges intent and nuance	Slow, inconsistent, a bottleneck at scale
Strict, no exceptions	Simple message; nothing to game	Blocks legitimate work; drives silent non-compliance
Governed exceptions process	Keeps standards credible and humane	Requires governance, records, and follow-through

The central tension is consistency versus flexibility. A standard exists to remove variation; an exceptions process exists to admit the variation that is genuinely warranted. Lean too far toward rigidity and people route around your standards. Lean too far toward laxity and the standards mean nothing. The exceptions process is the pressure valve that lets you hold a firm line and stay honest about reality.

Questions to discuss with your team

How many standards is the right number for your scale, and are yours drifting toward rigidity or toward inconsistency? The catalog itself is a trade-off: many detailed standards buy consistency, easy onboarding, and audit-readiness at the cost of rigidity and maintenance burden, while few high-level standards stay flexible but let each team relitigate the same questions. For a large enterprise or government body, the right size depends on how much variation you can genuinely tolerate versus how much your auditors and your onboarding need pinned down. Bring evidence: how many active standards you have, how many were reviewed in the last year, and how often teams re-debate things a standard could have settled. A catalog that outpaces practice becomes folklore, and one that is too thin pushes cost onto every team. Decide deliberately what deserves a standard, and prune the ones that no longer earn their keep.
Where does a standard’s letter pass automatically while its intent is quietly violated, and how will you catch that? Automation is consistent, tireless, and blind to intent, which means a linter or policy check can go green while the real goal (a sound abstraction, a wise trade-off, a genuinely accessible page) is missed. The rule of thumb is to automate the checkable and spend scarce human review on judgment, and the hard part is agreeing which standards have an intent that no CI gate can assert. Bring examples: standards people satisfy to the letter while defeating the purpose, such as a health-check endpoint that reports healthy while the service is broken, or code that passes the formatter but obscures meaning. In regulated settings, intent matters most for safety and security controls, where a green checkbox can hide real risk. Decide which standards keep a human reviewer specifically to judge intent, and word those standards around the outcome so both machine and reviewer aim at the same target.
Who owns the waiver-to-standard feedback loop, and at what point does a recurring exception force you to change the rule? A steady stream of waivers against one standard is data, not indiscipline, and the signal goes to waste unless someone is accountable for reading it and acting. The competing consideration is that revising a standard is real work, so it stays easier to keep rubber-stamping waivers than to fix the miscalibrated rule underneath them. Bring the numbers: which standards generate the most exceptions, whether waivers are actually time-boxed and reviewed on a cadence, and how many quietly became permanent. For safety-critical and security-critical standards in enterprise and government, a waiver must record compensating controls, a mitigation, the risk accepted, and a hard expiry, or a temporary deviation becomes undocumented policy that surfaces in the next audit. Assign an owner to review open waivers, set a threshold at which repeated exceptions trigger a standards revision, and treat a permanent exception as a defect in the standard to be fixed.
Does the right standard appear at the moment of work, or does it live in a folder nobody opens? A standard nobody can find is enforced by luck, and at scale most non-compliance is not defiance but ignorance: an engineer never knew the rule existed or could not locate it when it mattered. The competing consideration is effort, since surfacing a standard in the pull-request template, the linter’s error message, and the service scaffolding costs real integration work that a single central site does not. Bring evidence about discoverability: how engineers actually find standards today, whether a new hire can locate the accessibility or security rule that governs their task in under a minute, and how often reviewers cite a standard the author simply had not seen. For a large enterprise or government body, auditors increasingly ask not just whether a standard exists but whether it was communicated and accessible at the point of the decision, so treat surfacing as part of the standard, not an afterthought, and measure whether people can reach the rule when they need it.
Who owns each active standard, when was it last reviewed, and how would you spot the ones that have quietly rotted into folklore? Standards decay silently: a rule written three years ago for a framework you no longer use still sits in the catalog, cited selectively and trusted little, dragging the credibility of the standards that are still right. For a large organization the cost of ownership is the review cadence itself, which feels like overhead until an outage or an audit exposes a standard that no longer matches reality. Bring the numbers to the discussion: how many standards have a named owner (a role, not just a departed individual), how many were reviewed in the last year, how many are formally deprecated versus merely stale, and which are cited most and least. In enterprise and government settings, an auditor expects each standard to be versioned, dated, and demonstrably current, so agree a minimum review cadence, assign every standard an accountable owner, and retire the ones that no longer earn their keep before they undermine trust in the rest.
Is the authority to grant a waiver actually proportionate to the risk of the standard being waived? A style deviation and a security-control deviation are not the same decision, yet many organizations either route both to a heavyweight board (which grinds legitimate work to a halt) or let both slide through a single tech lead (which lets a serious risk be accepted by someone without the mandate to accept it). The tension is speed against accountability: too much approval friction drives silent non-compliance, while too little means consequential deviations get waved through in a chat thread. Bring a map of your standards to their approval authorities, plus a sample of recently granted waivers, and check whether anyone waived a safety-critical or security-critical control without the corresponding board, compensating control, mitigation, and recorded risk acceptance. For enterprise and government, this is a separation-of-duties question that regulators scrutinize directly, so tie each class of standard to a named authority proportionate to its risk, and make sure the person accepting a risk is genuinely accountable for the consequences.

Sector lens

Startup. Keep the catalog tiny: write down only the handful of rules whose absence would actually hurt you, such as a formatter config, a health-check requirement, and keyboard-navigable pages, and enforce each with a linter or CI check rather than a review meeting. Skip the waiver board entirely; a dated TODO in the code and a one-line note in the pull request is a perfectly good time-boxed exception at this scale. Your scarcest resource is engineering attention, so resist authoring standards for problems you do not yet have.

Small business. With no dedicated standards owner and a tight budget, buy your standards rather than build them: adopt published baselines such as the UK GDS Service Standard, OWASP security guidance, or your framework’s recommended lint rules, and lean on the checks already built into your tools and hosted CI. Keep one short page of local rules for the few things genuinely specific to you. Whoever leads engineering grants and records exceptions in the ticket, with an expiry date, so even a lightweight process stays honest.

Enterprise. The job is governance across many teams: one catalog, one template, rationale and examples for every standard, and policy-as-code that fails the pipeline for the mechanical majority. Run a waiver process whose approval authority is proportionate to risk, time-box every exception, review open waivers on a cadence, and mine recurring waivers as the signal that a standard needs to change. Measure the share of standards enforced automatically and the volume and age of open waivers, and report both to the governance function so standards stay a managed system rather than a graveyard.

Government. Publish your engineering standards openly in the DHCW and GDS tradition, and pair each with a checklist teams complete before a service assessment, so compliance is visible to the public and to oversight bodies. Make a named senior responsible owner the authority for consequential waivers, and require every exception to record the specific criterion, the compensating control or interim mitigation, a remediation plan, and a hard expiry. Procurement and transparency rules mean your standards and your deviations both become part of the public record, so treat auditability and traceability as design requirements from the start.

Examples

Startup. A seven-person startup keeps exactly three written standards (a shared formatter config, a health-check endpoint requirement, and “all public pages must be keyboard-navigable”), each enforced by a linter or CI check rather than a review meeting. When one engineer needs to ship a throwaway prototype that breaks the health-check rule, there is no waiver board: she leaves a dated TODO in the code and a one-line note in the pull request saying why and when she will fix it. That is a time-boxed exception at startup scale, honest and visible with no process overhead. The three checks pay for themselves by keeping code review about substance instead of style.

Enterprise. A global bank maintains an internal engineering handbook of about forty active standards, each in one template with a rationale, examples, and a linked good-practice checklist. Roughly 70% are enforced automatically: formatting, dependency policy, mandatory service metadata, and security controls encoded as policy-as-code that fails the CI pipeline. A payments team needs to ship on a database that does not yet support a mandated encryption feature. Rather than block the release, they file a waiver naming the standard, the compensating control (application-layer encryption), and a 90-day expiry. The security board grants it and records it. Ninety days later, the review finds the platform now supports the feature natively, and the waiver is closed. The standard held, the work shipped, and the deviation is fully traceable for the next audit.

Government. A national health agency modeled on the DHCW and GDS approach publishes its engineering standards openly, each paired with a checklist teams complete before a service assessment. Accessibility to WCAG 2.2 AA is a hard standard, enforced by an automated audit in CI plus a manual assessment. A legacy clinical system cannot immediately meet one accessibility criterion without risking patient-safety-critical functionality. The team requests a time-boxed exception. A named senior responsible owner grants it, and records the specific criterion, the interim mitigation (an assisted-access phone line), the remediation plan, and a six-month expiry, creating exactly the traceable, reviewable evidence that oversight bodies require (chapters 4.6, 10.4).

Business case: motivations, ROI, and TCO

A standard costs the time to write it, automate its check, and maintain it. The return is paid every time the check runs, and every time an engineer does not have to stop and debate a settled question. Standards convert recurring, distributed decision cost into a one-time authoring cost, the same economics as decision records (chapter 1.6), amplified because a standard governs thousands of future instances, not one past choice.

On total cost of ownership (TCO), the full lifetime cost of building, running, and maintaining a system, standards lower the largest line items: onboarding (new hires inherit consistency instead of reverse-engineering it), maintenance (uniform code is cheaper to change), and assurance (audits are cheaper when compliance is machine-checkable and deviations are already documented). The exceptions process protects that ROI from its main threat: standards decaying into ignored folklore. A credible waiver process keeps the standards trusted, and trusted standards are the ones people actually follow. The cost of skipping all this is invisible on any dashboard. It shows up as slow onboarding, inconsistent quality, and audit findings, and it compounds with every new team and every departure.

Anti-patterns and pitfalls

Rules without rationale: a standard nobody understands is a standard nobody can apply correctly or challenge honestly.
Aspirational, uncheckable standards: “code should be maintainable” is a value, not a standard; it cannot be enforced or contested.
No exceptions process: forces a false choice between blocking legitimate work and tolerating silent non-compliance.
Permanent exceptions: waivers with no expiry that quietly become the real, undocumented policy.
Waivers without records: deviations granted in a hallway or a chat thread, invisible to the next audit and the next engineer.
Ignoring the signal: granting the same exception repeatedly instead of reading it as proof the standard needs to change.
Enforcement-by-nagging: relying on reviewers to catch what a linter should, wasting judgment on the mechanical.
Standards graveyard: a catalog written once, owned by no one, never reviewed, cited selectively, trusted by few.
Jargon gatekeeping: standards written for their authors rather than their readers, with no examples to copy.

Maturity model

Level 1 (Initiate): Standards are tribal knowledge in senior engineers’ heads, applied reactively. Enforcement is ad hoc code-review nagging; deviations are invisible; “the way we do it” varies by team and by who reviewed the change.
Level 2 (Develop): Some standards are written down, in inconsistent formats and scattered locations, and adoption varies widely from team to team. Enforcement is mostly manual. Exceptions happen informally, without records or expiry dates.
Level 3 (Standardize): A single catalog, one template, rationale and examples for each standard, and good-practice checklists, applied consistently across teams. Automated enforcement for the mechanical majority. A documented exceptions process with named approvers, recorded rationale, and time-boxed waivers.
Level 4 (Manage): The standards system is measured against baselines. You track the share of standards enforced automatically versus by human review, waiver volume per standard, time-to-close, and how many waivers expired while still open, and you report these to the governance function. Approval authority is proportionate to risk and audited; review cadence and expiry are enforced on evidence rather than goodwill; a standard whose waiver rate crosses an agreed threshold is flagged for revision.
Level 5 (Orchestrate): Standards are surfaced at the moment of work and enforced by policy-as-code and fitness functions. Waivers are mined as signal so recurring exceptions continuously drive standards to evolve, and the catalog is rebalanced as practice shifts. Standards, checklists, and waivers are one adaptive living system integrated across onboarding, delivery, and audit.

Ideas for discussion

Which of your standards can you state with a testable rule and a clear rationale, and which are really just aspirations?
What share of your standards are enforced automatically versus by a reviewer noticing? What would it take to move ten more into CI?
Where do deviations happen today, and would you even know? Are they recorded and time-boxed, or silent?
Who is allowed to grant a waiver against your most safety- or security-critical standard, and is that authority proportionate to the risk?
Look at your most-waived standard. Is it a discipline problem, or is the standard simply wrong?
When was each active standard last reviewed, and who owns it? Which have quietly become folklore?

Key takeaways

An engineering standard is a rule stated as an outcome, with a rationale, examples, and a way to check it: if it can’t be checked, it isn’t a standard yet.
Pair each standard with a good-practice checklist so people can self-verify, following the public-sector handbook pattern (NHS Wales / DHCW, UK GDS).
Store standards in version control, keep them living with named owners and review dates, and surface them at the moment of work.
Automate the checkable with linters, policy-as-code, and fitness functions; reserve human review for judgment.
Govern deviations with a documented, time-boxed exceptions/waiver process: named approver, recorded rationale, mandatory expiry, periodic review.
A recurring exception is a signal to fix the standard, not just to keep granting waivers: “the exception proves the rule.” See chapters 1.5 (governance), 1.6 (decision records), 2.1 (coding standards), 12.2 (checklists), and 12.3 (templates).

References and further reading

UK Government Digital Service, Government Service Standard, Technology Code of Practice, and GOV.UK Service Manual.
NHS Digital / NHS England, Service Standard and engineering guidance.
Digital Health and Care Wales (DHCW) / NHS Wales, published engineering standards and good-practice checklists.
Scott Bradner, RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels (IETF, 1997).
World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG) 2.2.
Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures (fitness functions as automated governance).
Torin Sandall et al., Open Policy Agent documentation (policy-as-code).
GitLab, The GitLab Handbook: a public example of living, version-controlled organizational standards.
Google, Software Engineering at Google (Winters, Manshreck, Wright): standards, readability, and automated enforcement at scale.
Atul Gawande, The Checklist Manifesto: the case for checklists as professional practice.