Every Rule Has Legitimate Exceptions
The rule: 'Use async/await for all asynchronous operations.' The exception: event listeners in the DOM API require callback functions — async/await does not work in addEventListener. The rule: 'No console.log in production code.' The exception: CLI tools and build scripts where the structured logger is not available. The rule: 'All database queries through the ORM.' The exception: a complex aggregation query that the ORM cannot express. Every rule: has edge cases where strict adherence produces worse code than a thoughtful deviation.
The problem with unmanaged exceptions: developers override rules ad-hoc with no documentation. Over time: overrides accumulate, nobody knows which are legitimate exceptions and which are shortcuts, and the rules lose authority ('everyone overrides rule #7 — it is basically optional'). Managed exceptions: documented, justified, and tracked. They preserve rule authority while acknowledging reality.
The exception spectrum: inline exception (built into the rule itself — 'use async/await except for DOM event listeners'), project exception (a specific project legitimately needs a different approach — documented in the project's team rules), and individual exception (a one-time deviation for a specific code change — documented in the code comment). Each level: different documentation and governance requirements.
Step 1: Build Common Exceptions into the Rule
If an exception applies to most projects: build it into the rule. Before: 'Use async/await for all asynchronous operations.' After: 'Use async/await for all asynchronous operations. Exception: DOM event listeners and Node.js event emitters use callback functions (addEventListener, emitter.on).' The built-in exception: the AI reads it and applies the exception automatically. No developer override needed. No documentation needed. The rule handles its own edge cases.
When to build in exceptions: the exception applies to most or all projects (not just one team's unique case), the exception is well-defined (specific scenarios, not vague 'when it makes sense'), and the exception is permanent (not a temporary workaround). If the exception only applies to one project: it belongs in the project's team rules, not in the organization rule. AI rule: 'Built-in exceptions: for universal edge cases. Project exceptions: for team-specific deviations. Do not clutter organization rules with one-project exceptions.'
The exception format: 'Exception: [specific scenario] — [what to do instead]. Reason: [why the exception exists].' Example: 'Exception: Express middleware error handlers require 4 parameters (err, req, res, next) — use the Express error handler pattern, not the Result pattern. Reason: Express routing depends on the 4-parameter signature to identify error handlers.' The format: specific, actionable, and justified. AI rule: 'Exception clauses: as specific as the rules they modify. Vague exceptions ("when appropriate") are not exceptions — they are loopholes.'
If every Express developer overrides the error handling rule for middleware: the exception should be in the rule, not in 15 different project overrides. 'Use Result pattern for error handling. Exception: Express middleware uses the 4-parameter error handler (err, req, res, next) — Express routing requires this signature.' Built-in exception: the AI handles it automatically. No override needed. No documentation needed. The rule governs its own edge cases.
Step 2: Managing Project-Level Exceptions
Project exceptions: a specific project legitimately needs to deviate from an organization rule. Example: the organization rule says 'use the Result pattern for error handling.' The legacy project: uses a different error handling library that predates the Result pattern. Migrating: would require rewriting 200 functions. The exception: the legacy project continues using the old pattern until a major refactoring is planned. Document: in the project's team rules with the reason and expiration.
Exception documentation: the project's CLAUDE.md (or team rules section) includes: 'Override: organization rule says use Result pattern. This project uses the legacy ErrorWrapper class. Reason: migration would require rewriting 200 functions. Plan: migrate during the Q3 backend refactoring. Until then: new code uses ErrorWrapper for consistency with existing code. After Q3: switch to Result pattern.' The documentation: explains the deviation, the reason, and the plan to resolve it.
Exception tracking: for organizations with formal governance, track exceptions in a register. The register: exception ID, project, rule being overridden, reason, approval date, approved by, and expiration/review date. The register: reviewed quarterly. Expired exceptions: either renewed (with updated justification) or resolved (the project adopted the standard rule). AI rule: 'Exceptions without expiration dates: become permanent deviations that nobody reviews. Every exception: has a review date. The review: either renews or resolves.'
Exception request: 'The legacy project uses ErrorWrapper instead of Result pattern.' Approved: March 2026. Without expiration: the exception is still active in March 2028. Nobody reviews it. The Q3 refactoring that was supposed to migrate: never happened. The exception: effectively permanent. With expiration (review by Q4 2026): the quarterly review surfaces it. The team: either extends with updated justification or resolves. Expiration dates: force periodic re-evaluation.
Step 3: Preventing Exceptions from Becoming Loopholes
The loophole risk: too many exceptions → the rules are effectively optional. If every project has exceptions to the security rules: the security rules do not protect anything. Guardrails: security rules have no exceptions (parameterized queries, no secrets in code — these are absolute), exception requests require justification (not just 'this is inconvenient'), exceptions have expiration dates (force periodic review), and exception trends are tracked (if many teams request the same exception: the rule may need revision).
The 10% threshold: if more than 10% of projects have exceptions to the same rule: the rule needs revision, not more exceptions. The exceptions: are signal that the rule does not fit reality. Action: revise the rule to accommodate the common case (add a built-in exception), or split the rule into two (one for the common case, one for the specific case). AI rule: 'Many exceptions to the same rule = the rule is wrong. Fix the rule. Do not accumulate exceptions.'
Distinguishing exceptions from non-compliance: an exception: is documented, justified, approved, and has an expiration. Non-compliance: is undocumented, unjustified, and untracked. The difference: governance. When a team requests an exception: they go through the process (document, justify, get approval). When a team simply ignores a rule: that is non-compliance (investigate and address). AI rule: 'Exceptions are governed. Non-compliance is not. If a team overrides without documenting: that is non-compliance, not an exception. The process: protects rule authority.'
5 out of 50 projects request exceptions to the error handling rule (all for the same reason: Express middleware). That is 10%. The rule: does not account for a common scenario. The fix: add the Express exception to the rule itself (built-in exception). Now: 0 projects need exceptions. The 10% threshold: transforms individual exceptions into rule improvements. If many teams deviate for the same reason: the reason is valid and the rule should accommodate it.
Rule Exceptions Summary
Summary of handling AI rule exceptions.
- Reality: every rule has legitimate edge cases. Managed exceptions preserve rule authority
- Inline exceptions: built into the rule for universal edge cases. AI applies automatically
- Project exceptions: documented in team rules with reason, plan, and expiration date
- Exception format: specific scenario + alternative action + reason. No vague loopholes
- Tracking: exception register with ID, project, reason, approval, and review date
- Security rules: no exceptions. Parameterized queries and no-secrets rules are absolute
- 10% threshold: if 10%+ of projects have the same exception → revise the rule
- Exception vs non-compliance: exceptions are documented and governed. Non-compliance is not