Exception Precedence Governance

2. Summary

Exception Precedence Governance requires that when exemptions and prohibitions collide — when one policy rule grants an exception while another imposes a restriction on the same action — the system resolves the conflict through a deterministic, documented, and auditable precedence mechanism rather than through implicit evaluation order, last-write-wins semantics, or undefined behaviour. Every conflict resolution must be explainable: for any decision where multiple rules applied, the system must be able to state which rules were considered, which prevailed, and why. This dimension ensures that the exception mechanism cannot silently override safety or compliance prohibitions.

3. Example

Scenario A — Exemption Silently Overrides Sanctions Prohibition: A financial-value agent applies two policy rules. Rule A: "Block all transactions to entities on the OFAC sanctions list." Rule B: "Approved vendor exemptions: the following entities are pre-approved for expedited processing without additional checks." A sanctioned entity is added to the approved vendor list by an operations team member who does not check the sanctions list. The rule engine evaluates Rule B (exemption) after Rule A (prohibition). Because the engine uses last-evaluated-wins semantics, the exemption overrides the sanctions block. 14 transactions totalling £2.3 million are processed to the sanctioned entity before the conflict is detected.

What went wrong: The precedence mechanism was implicit (evaluation order) and allowed exemptions to override prohibitions without explicit authorization. No conflict detection mechanism identified the contradiction between the sanctions list and the approved vendor list. Consequence: Sanctions violation, potential criminal liability, regulatory enforcement, estimated remediation cost exceeding £15 million including fines.

Scenario B — Conflicting Jurisdictional Rules Produce Non-Deterministic Behaviour: A cross-border agent serves customers in the UK and Germany. UK policy: "Customers under 18 cannot open investment accounts." German policy: "Customers aged 16-17 can open custodial investment accounts with parental consent." A 17-year-old German resident applies. Both rules match. The rule engine has no documented precedence for jurisdictional conflicts — the outcome depends on which rule the engine happens to evaluate first, which varies depending on server load and rule caching. On Monday the application is approved; an identical application on Wednesday is rejected.

What went wrong: No precedence was defined for conflicting jurisdictional rules. The engine resolved the conflict through non-deterministic evaluation order. Two identical inputs produced different outputs, which is a fundamental governance failure. Consequence: Inconsistent treatment of customers, regulatory finding for unfair treatment, reputational damage, inability to explain to the customer why their application was treated differently from an identical one.

Scenario C — Cascading Exemptions Create Unintended Permission: An enterprise workflow agent has three rules. Rule 1: "All procurement above £10,000 requires CFO approval." Rule 2: "Exception: IT hardware purchases are exempt from CFO approval up to £50,000." Rule 3: "Exception: purchases under existing framework agreements are exempt from category-specific limits." An employee purchases £85,000 of IT hardware under a framework agreement. Rule 3 exempts the purchase from Rule 2's £50,000 limit. Rule 2 exempts the purchase from Rule 1's CFO approval requirement. The cascading exemptions create a path where an £85,000 purchase requires no approval at all — an outcome that no individual exemption was intended to create.

What went wrong: Exemptions were designed independently and their cascading interactions were not analysed. No mechanism limited the combined effect of multiple exemptions. Consequence: £85,000 procurement without approval, budget control failure, audit finding, potential disciplinary action.

4. Requirement Statement

Scope: This dimension applies to all AI agents governed by policy rule sets where rules can conflict — where two or more rules can apply to the same input and produce different outcomes. This includes any system with exemptions, exceptions, overrides, or jurisdiction-specific rules. Systems with a single, non-conflicting rule set are excluded, though organisations should verify this property formally rather than assuming it. The scope extends to conflicts that arise from rule interactions across different policy domains (e.g., a compliance prohibition interacting with an operational exemption), across jurisdictions (AG-274), and across time windows (AG-273). Conflicts between rules from different sources (e.g., organisation policy vs. regulatory requirement) are within scope.

4.1. A conforming system MUST define a documented, deterministic precedence mechanism that resolves every possible conflict between rules, such that the same inputs always produce the same output regardless of evaluation order, caching state, or server load.

4.2. A conforming system MUST enforce that safety and compliance prohibitions cannot be overridden by operational exemptions unless the exemption is explicitly tagged as a compliance-aware override with documented regulatory justification.

4.3. A conforming system MUST log every conflict resolution, recording: the conflicting rules, the input that triggered the conflict, the precedence mechanism applied, the winning rule, and the outcome.

4.4. A conforming system MUST detect and flag contradictions when a new exemption is added that conflicts with an existing prohibition, before the exemption is activated.

4.5. A conforming system MUST limit cascading exemptions — define the maximum depth of exemption chains and block exemptions from overriding other exemptions beyond the defined depth.

4.6. A conforming system SHOULD implement a precedence hierarchy with at least four levels: (1) safety prohibitions, (2) regulatory/compliance prohibitions, (3) organisational policy rules, (4) operational exemptions — where higher-level rules override lower-level rules by default.

4.7. A conforming system SHOULD provide a conflict simulation tool that, given a proposed new rule or exemption, identifies all existing rules it could conflict with and displays the resolution outcome for each potential conflict.

4.8. A conforming system MAY implement formal conflict analysis using model checking or satisfiability solving to prove that the rule set is free of unresolved conflicts.

5. Rationale

Exception precedence is one of the most dangerous areas in policy governance because exemptions appear individually reasonable but interact in ways that undermine the controls they were designed to preserve. Every exemption weakens a control. Cascading exemptions can eliminate a control entirely. Unmanaged precedence means the system's behaviour in conflict situations is unpredictable — which is incompatible with governance.

The requirement for determinism (4.1) exists because non-deterministic conflict resolution is fundamentally ungovernable. If the same inputs can produce different outputs depending on evaluation order, then no test can prove correctness and no audit can reconstruct the decision logic. The outcome of any individual decision becomes a function of runtime state rather than policy intent.

The hierarchy requirement (4.6) encodes a principle that most organisations agree with in theory but fail to implement in practice: safety and compliance rules must take precedence over operational convenience. An exemption created for operational efficiency must not be able to override a sanctions check, a safety limit, or a regulatory requirement. Without an explicit hierarchy, the precedence defaults to whatever the implementation happens to do — which in most rule engines is evaluation order, last-write-wins, or most-specific-rule-wins, none of which respect the safety/compliance distinction.

The cascading exemption limit (4.5) addresses a failure mode unique to exception systems: the exemption-of-an-exemption chain. If Rule A prohibits an action, Rule B exempts a category from Rule A, and Rule C exempts a sub-category from Rule B's conditions, then the combined effect may permit an action that Rule A was specifically designed to prevent. Without a depth limit, exemption chains can grow unbounded as different teams independently create exemptions for their operational needs, each unaware of the others.

6. Implementation Guidance

Recommended patterns:

• Explicit precedence tags. Every rule is assigned a precedence level from a defined hierarchy (e.g., Level 1: Safety, Level 2: Regulatory, Level 3: Organisational, Level 4: Operational). When rules conflict, the higher-level rule prevails. If rules at the same level conflict, a secondary resolution mechanism applies (e.g., most-specific-rule-wins, or deny-by-default). Tags are assigned during rule authoring and cannot be modified without change control per AG-007.
• Conflict detection at rule activation. When a new rule or exemption is proposed, the system evaluates it against all existing rules to identify potential conflicts. Each conflict is classified: (a) the new rule is always overridden by the existing rule (no concern), (b) the new rule always overrides the existing rule (requires review), (c) the outcome depends on input (requires precedence definition). Conflicts of type (b) or (c) require explicit approval before the new rule is activated.
• Conflict resolution log. Every decision where multiple rules matched logs: the set of matching rules, the conflict type, the precedence mechanism applied, the winning rule, and the losing rules. This log supports audit, debugging, and customer-facing explanations. The log entry includes the policy version identifier per AG-269.
• Cascading exemption depth limit. Define a maximum exemption chain depth (recommended: 2 — an exemption can exist for a rule, and an exemption-of-an-exemption can exist, but no further chaining). When the depth limit is reached, the system blocks additional exemptions and requires the rule set to be refactored to express the intended behaviour directly.
• Deny-by-default for unresolved conflicts. When the precedence mechanism cannot determine a winner (e.g., two rules at the same level with no secondary resolution), the system denies the action and escalates for human resolution rather than permitting the action. This is consistent with the fail-safe principle.

Anti-patterns to avoid:

• Implicit evaluation order as precedence. Many rule engines resolve conflicts by evaluation order — whichever rule fires first (or last) wins. This creates non-determinism because evaluation order can change with rule engine version, caching, or load. It also means precedence is invisible to policy authors and auditors.
• Last-write-wins for conflicting rules. If the most recently added rule always wins, then adding an operational exemption after a safety prohibition silently overrides the prohibition. This is the failure in Scenario A.
• Allowing exemptions to override safety/compliance rules without explicit tagging. Operational exemptions should not be able to override safety or compliance rules. If an exemption genuinely needs to override a compliance rule (rare but possible — e.g., a regulatory sandboxing arrangement), it must be explicitly tagged as a compliance-aware override with documented justification.
• Independent exemption management by different teams. When the compliance team, operations team, and business team can each create exemptions independently, cascading interactions are inevitable. All exemptions must be visible to a single conflict detection mechanism.
• Treating precedence as a technical implementation detail. Precedence is a policy decision, not a technical decision. The choice of whether a safety rule overrides an operational exemption is a governance question that must be answered by policy owners, not left to the rule engine's default behaviour.

Industry Considerations

Financial Services. Sanctions screening rules must be the highest precedence in any conflict. The FCA and OFAC expect that no operational exemption, efficiency optimisation, or customer convenience rule can override a sanctions check. Regulatory requirements (PSD2 strong customer authentication, MiFID II suitability) should have precedence over organisational policies. The precedence hierarchy should be documented in the firm's compliance manual and reviewed annually.

Healthcare. Clinical safety rules (contraindication checks, allergy alerts, dosage limits) must have the highest precedence. Administrative exemptions (e.g., formulary overrides for cost management) must not override clinical safety rules. Where a clinical exemption is genuinely required (e.g., a specialist prescriber overriding a standard dosage limit), the override must be logged with clinical justification and the prescriber's identity.

Critical Infrastructure. Safety interlock rules must have absolute precedence over operational efficiency rules. An optimisation rule that increases throughput must not override a safety limit that prevents equipment damage or personnel injury. IEC 61511 requires that safety instrumented functions cannot be overridden by non-safety functions.

Maturity Model

Basic Implementation — A documented precedence hierarchy exists (e.g., safety > compliance > organisational > operational). Rules are tagged with their precedence level. Conflicts are resolved by level. Conflict resolution is logged. However, conflict detection is manual — new rules are checked against existing rules by a human reviewer.

Intermediate Implementation — Automated conflict detection at rule activation identifies all potential conflicts with existing rules. Cascading exemption depth is limited to a defined maximum. A conflict simulation tool allows policy authors to preview the effect of a proposed rule before activation. Deny-by-default applies for unresolved conflicts. Conflict resolution logs are structured and queryable.

Advanced Implementation — All intermediate capabilities plus: formal conflict analysis using model checking or SAT solvers proves the rule set is free of unresolved conflicts for all possible inputs. Conflict detection covers not just pairwise rule interactions but higher-order combinations. Automated alerts notify policy owners when upstream rule changes create new conflicts with downstream rules. Independent verification of the precedence mechanism confirms that safety and compliance rules cannot be overridden by lower-level rules under any input combination.

7. Evidence Requirements

Required artefacts:

• Precedence hierarchy documentation. The defined precedence hierarchy, showing levels, override rules, and the authority that approved the hierarchy. Format: structured policy document or configuration export.
• Conflict detection results. Evidence that the most recent 5 rule additions or modifications triggered conflict detection, showing: rules analysed, conflicts identified, resolution applied, and approval for any conflicts requiring review. Format: structured log or report.
• Conflict resolution log. A sample of production decisions (minimum 500 or 10% of total, whichever is smaller) where multiple rules matched, showing: matching rules, precedence applied, winning rule, and outcome. Format: structured log export.
• Cascading exemption inventory. An inventory of all active exemptions, showing: the rule each exempts, the exemption depth (1 = direct exemption, 2 = exemption of exemption), and the approval authority for each. Format: structured data.

Retention requirements:

• Conflict resolution logs: aligned with decision log retention per AG-269. Precedence hierarchy versions: retained for the full life of the system.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.

8. Test Specification

Test 8.1: Deterministic Conflict Resolution

• Stimulus: Submit the same input 100 times where two rules conflict. Vary: server load, time of day, caching state.
• Expected behaviour: All 100 submissions produce the same outcome.
• Pass criteria: 100% identical outcomes across all 100 submissions.
• Fail criteria: Any submission produces a different outcome, indicating non-deterministic resolution.

Test 8.2: Safety Prohibition Override Resistance

• Stimulus: Create an operational exemption that conflicts with a safety prohibition. Submit an input that triggers both.
• Expected behaviour: The safety prohibition prevails. The exemption does not override the prohibition.
• Pass criteria: The safety prohibition is enforced and the exemption is logged as overridden.
• Fail criteria: The operational exemption overrides the safety prohibition.

Test 8.3: Compliance Prohibition Override Resistance

• Stimulus: Create an operational exemption that conflicts with a compliance prohibition (e.g., a sanctions check). Submit an input that triggers both.
• Expected behaviour: The compliance prohibition prevails. The exemption does not override the prohibition.
• Pass criteria: The compliance prohibition is enforced.
• Fail criteria: The operational exemption overrides the compliance prohibition.

Test 8.4: Cascading Exemption Depth Limit

• Stimulus: Create an exemption chain that exceeds the defined depth limit (e.g., an exemption-of-an-exemption-of-an-exemption where the limit is 2).
• Expected behaviour: The system blocks the creation of the exemption that exceeds the depth limit.
• Pass criteria: The excessive-depth exemption is rejected.
• Fail criteria: The excessive-depth exemption is accepted and activated.

Test 8.5: Conflict Detection on New Rule Addition

• Stimulus: Add a new rule that conflicts with an existing rule at the same precedence level. Observe whether the system detects and flags the conflict.
• Expected behaviour: The system identifies the conflict, classifies it, and requires explicit resolution before the new rule is activated.
• Pass criteria: The conflict is detected and the new rule is not activated until resolution is defined.
• Fail criteria: The new rule is activated without conflict detection or resolution.

Test 8.6: Conflict Resolution Logging

• Stimulus: Submit 50 inputs that each trigger at least two conflicting rules. Query the conflict resolution log.
• Expected behaviour: All 50 decisions have conflict resolution log entries showing: conflicting rules, precedence mechanism, winning rule, and outcome.
• Pass criteria: 100% of multi-rule decisions have complete conflict resolution log entries.
• Fail criteria: Any multi-rule decision lacks a conflict resolution log entry.

Test 8.7: Unresolved Conflict Defaults to Deny

• Stimulus: Create two rules at the same precedence level that conflict, with no secondary resolution mechanism defined. Submit an input that triggers both.
• Expected behaviour: The system denies the action and escalates for human resolution.
• Pass criteria: The action is denied rather than permitted when the conflict is unresolvable.
• Fail criteria: The action is permitted despite an unresolvable conflict.

Conformance Scoring

• Score 0: No documented precedence mechanism — conflicts are resolved by implicit engine behaviour (evaluation order, last-write-wins) without documentation or logging.
• Score 1: A documented precedence hierarchy exists and rules are tagged, but conflict detection is manual and conflict resolution is not systematically logged.
• Score 2: Automated conflict detection at rule activation, conflict resolution logged for all multi-rule decisions, cascading exemption depth limited, and safety/compliance prohibitions cannot be overridden by operational exemptions.
• Score 3: All Score 2 capabilities plus formal conflict analysis proving the rule set is conflict-free for all inputs, automated higher-order interaction detection, and independently verified precedence mechanism integrity.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Direct requirement
EU AI Act	Article 14 (Human Oversight)	Supports compliance
OFAC Sanctions Regulations	31 CFR Part 501	Direct requirement
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.2, MANAGE 2.2	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks)	Supports compliance
IEC 61511	Clause 11 (SIS Design and Engineering)	Supports compliance

EU AI Act — Article 9 (Risk Management System)

Article 9 requires risk management measures that are appropriate and effective. A rule set with unmanaged precedence — where exemptions can silently override safety rules — is not an effective risk management measure. The requirement for deterministic, documented precedence directly implements Article 9's expectation that risk controls function as intended.

OFAC Sanctions Regulations — 31 CFR Part 501

Sanctions compliance requires that no business process, exemption, or optimisation bypasses sanctions screening. Exception precedence governance implements this by ensuring sanctions rules are at the highest precedence level and cannot be overridden by operational exemptions. The sanctions violation in Scenario A is a strict liability offence — intent is irrelevant.

FCA SYSC — 6.1.1R

The FCA expects firms to maintain systems and controls that ensure compliance. A system where exemptions can silently override compliance rules is a control failure. The FCA would expect to see: a documented precedence hierarchy, evidence of conflict detection, and logs showing that compliance rules prevailed over conflicting exemptions.

IEC 61511 — Clause 11

IEC 61511 requires that safety instrumented functions maintain their integrity against override by non-safety functions. Exception precedence governance implements this for AI-governed safety systems by ensuring safety rules cannot be overridden by operational exemptions.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	All decisions affected by the conflicting rules — potentially cross-organisation for sanctions and compliance violations

Consequence chain: Unmanaged exception precedence allows exemptions to silently override safety and compliance rules. The immediate technical failure is an exemption overriding a prohibition that was specifically designed to prevent certain actions. The operational impact is that prohibited actions are permitted — sanctions violations, non-compliant lending, unsafe operating conditions. The regulatory consequence varies by domain: sanctions violations carry strict liability with penalties up to $10 million per violation (OFAC) or unlimited fines (UK); compliance rule overrides in financial services trigger FCA enforcement; safety rule overrides in critical infrastructure can cause physical harm and IEC 61511 non-compliance. The cascading exemption failure (Scenario C) creates a particularly dangerous condition: the combined effect of individually reasonable exemptions produces an outcome that no individual exemption was intended to create, and the failure path is invisible to anyone reviewing exemptions individually. The business consequence includes regulatory enforcement, potential criminal liability for sanctions violations, and inability to explain decisions to affected parties because the conflict resolution was implicit and undocumented.

Cross-references: AG-135 (Policy Precedence and Conflict Arbitration) provides the foundational precedence framework that AG-272 extends specifically to exemption conflicts. AG-134 (Machine-Checkable Policy Semantics) enables formal conflict analysis. AG-271 (Rule-Test Coverage Governance) requires tests for rule interactions including precedence conflicts. AG-273 (Temporal Policy Trigger Governance) and AG-274 (Geographic Policy Trigger Governance) introduce time-based and jurisdiction-based triggers that create additional conflict surfaces. AG-269 (Policy Version Pinning Governance) ensures that conflict resolution logs reference the exact policy version. AG-007 (Governance Configuration Control) governs changes to the precedence hierarchy and exemption inventory. AG-136 (Independent Control-Plane Separation) supports the requirement that conflict resolution logic operates independently of the agent.