Exceptions and escalation

How to handle policy exceptions without weakening governance.

Principle

Exceptions should be controlled, traceable, and temporary.

Exception policy

Every exception must include:

• reason: what's being exempted and why
• owner: who's accountable
• scope: what it applies to
• expiry date: when it must be re-reviewed
• rollback or remediation plan: how it gets cleaned up

No permanent exceptions by default.

Exception levels

Level 1: Local exception

• scoped to one artifact or file set
• short expiry
• no broad policy change

Level 2: Domain exception

• scoped to a rule domain (for example, token-naming migration)
• steward approval required
• explicit impact tracking

Level 3: System exception

• cross-domain or org-wide impact
• governance lead approval required
• mandatory review checkpoint

Escalation triggers

Escalate when any of the following occur:

• repeated violations of the same rule category
• increasing exception count over time
• policy blocks critical delivery repeatedly
• security, accessibility, or compliance-critical rules violated
• conflicting ownership decisions

Escalation path

1. Capture issue and context
2. Classify severity and blast radius
3. Assign governance owner
4. Choose immediate containment action
5. Decide rule adjustment, exception extension, or rejection
6. Document final decision and follow-up tasks

AI-specific exception handling

For AI-generated changes:

• keep proposal artifacts when exceptions are requested
• require explicit human approval in Guard / Enforce modes
• log model, tool, and context for post-incident analysis

Review cadence

Run exception reviews at minimum:

• weekly for active programs
• monthly for mature, stable systems

Review outcomes:

• remove expired exceptions
• convert recurring exceptions into updated policy
• tighten policy where exception abuse appears

Metrics to track

• active exceptions by level
• expired exceptions not remediated
• repeat exceptions by rule
• time-to-resolution by severity