Policy Precedence and Conflict Arbitration Governance

2. Summary

Policy Precedence and Conflict Arbitration Governance requires that every AI agent governance system implements a formally defined, deterministic mechanism for resolving conflicts between multiple applicable policies. In any non-trivial deployment, an agent's actions are governed by multiple overlapping policies — organisational policy, regulatory policy, role-specific policy, time-bounded policy, jurisdiction-specific policy, and others. When two or more policies produce contradictory enforcement decisions for the same action, the system must resolve the conflict through a precedence mechanism whose rules are explicit, auditable, and deterministic. A conforming system must never silently drop a conflicting policy, apply policies in an undefined order, or allow the agent to choose which policy to follow.

3. Example

Scenario A — Conflicting Jurisdictional Policies Permit Sanctioned Transaction: A multinational financial services firm deploys an AI agent for cross-border payments. The agent operates under three policy layers: (1) a global corporate policy permitting payments to all non-sanctioned entities, (2) a UK-specific policy that restricts payments to entities on the OFSI Consolidated List, and (3) a US-specific policy that restricts payments to entities on the OFAC SDN List. The agent processes a payment to an entity that appears on the OFAC SDN List but not the OFSI Consolidated List. The UK-specific policy permits the payment; the US-specific policy denies it. The system has no defined precedence between jurisdictional policies. The payment processor applies the first matching policy (UK), and the payment executes.

What went wrong: Two jurisdiction-specific policies produced contradictory decisions. No precedence rule defined which policy takes priority when a transaction touches multiple jurisdictions. The system defaulted to first-match ordering, which is implementation-dependent and not a governance decision. Consequence: payment to an OFAC-listed entity, triggering US secondary sanctions exposure, potential penalty of up to $20,000,000 per violation under IEEPA, loss of US correspondent banking relationships, and board-level notification obligation.

Scenario B — Role Policy Overrides Safety Policy Due to Implicit Precedence: An organisation deploys an AI agent managing a chemical processing facility. The agent operates under (1) a safety policy: "Do not increase reactor temperature above 350°C under any circumstances" and (2) a production optimisation role policy: "Maximise throughput by adjusting parameters within approved ranges — reactor temperature range 200°C–400°C." The production role policy was authored by the operations team; the safety policy was authored by the safety engineering team. Both policies are loaded into the same policy engine. The policy engine evaluates role policies before safety policies (the default order in the configuration). The agent increases reactor temperature to 385°C, which is within the role policy's approved range but violates the safety policy's absolute cap.

What went wrong: The implicit evaluation order gave role policies precedence over safety policies. No explicit precedence rule declared that safety policies always override role policies. The two policies were authored by different teams with no awareness of the conflict. The policy engine processed them in configuration order without conflict detection. Consequence: reactor temperature exceedance, potential exothermic runaway, emergency shutdown triggered, 72-hour production halt costing approximately £2,400,000, HSE investigation and potential enforcement notice.

Scenario C — Temporal Policy Conflict Creates Enforcement Gap: An organisation's standard policy restricts an AI agent to processing refunds up to £500. During a promotional period, a temporary policy is activated: "For the period 1-31 March 2026, the agent may process refunds up to £2,000 for orders placed during the promotion." On 1 April 2026, the temporary policy's expiry mechanism fails — the cron job that deactivates it does not execute due to a server restart. The temporary policy remains active alongside the standard policy. From 1 April onward, the agent processes refunds up to £2,000 against the expired promotion. Over 14 days, the agent processes £847,000 in refunds that exceed the standard policy's £500 limit.

What went wrong: The temporal policy had no formal expiry mechanism integrated into the policy evaluation engine. Expiry was delegated to an external process (cron job) that failed independently. The policy engine had no mechanism to detect that a time-bounded policy had exceeded its validity period. No precedence rule specified that standard policies resume when temporary policies expire. Consequence: £847,000 in excess refunds over 14 days, profit impact, internal investigation, remediation costs including manual review of all refunds processed during the window.

4. Requirement Statement

Scope: This dimension applies to all AI agent deployments where more than one governance policy can apply to the same action. This includes virtually all production deployments, because even a single-purpose agent typically operates under multiple policy layers: an organisational policy, a regulatory policy, a role-specific policy, and potentially jurisdiction-specific, time-bounded, or context-dependent policies. The scope extends to any mechanism that combines, merges, layers, or sequences multiple policy evaluations into a single enforcement decision. Systems where only a single, monolithic policy governs all agent actions are technically out of scope but should anticipate future policy layering and implement precedence mechanisms proactively. The scope includes both explicit policy conflicts (two policies produce opposite decisions) and implicit conflicts (two policies define different values for the same parameter, such as different transaction limits).

4.1. A conforming system MUST implement a formally defined precedence order for all policy layers, expressed as a machine-checkable precedence specification (per AG-134) that is versioned and auditable independently of the policies it governs.

4.2. A conforming system MUST detect conflicts between applicable policies before rendering an enforcement decision, rather than silently applying one policy and ignoring others.

4.3. A conforming system MUST resolve all detected conflicts using the defined precedence order, producing a single deterministic enforcement decision for every action.

4.4. A conforming system MUST log every conflict detection and resolution event, including the conflicting policies, the precedence rule applied, the resulting enforcement decision, and the complete evaluation context.

4.5. A conforming system MUST enforce a most-restrictive-wins default for safety-classified policies — when a safety policy and any other policy conflict, the safety policy takes precedence unless the precedence specification explicitly defines an alternative with documented risk acceptance.

4.6. A conforming system SHOULD implement static conflict analysis at policy deployment time, identifying potential conflicts between a candidate policy and all existing policies before the candidate is activated.

4.7. A conforming system SHOULD support temporal precedence rules that automatically activate and deactivate time-bounded policies based on formal temporal constraints evaluated within the policy engine, not delegated to external scheduling mechanisms.

4.8. A conforming system SHOULD provide a conflict resolution audit trail that enables an auditor to trace any historical enforcement decision back to the specific policies, the specific conflict (if any), and the specific precedence rule that determined the outcome.

4.9. A conforming system MAY implement jurisdiction-aware precedence that automatically applies the most restrictive applicable jurisdictional policy when an action involves multiple jurisdictions, with the set of applicable jurisdictions determined by the action's attributes (counterparty location, data residency, agent deployment location).

5. Rationale

Policy Precedence and Conflict Arbitration Governance addresses the reality that production AI agent deployments operate under multiple overlapping governance policies. This multiplicity is not a design flaw — it reflects the genuine complexity of governance in real organisations. An agent executing financial transactions may be subject to corporate risk policy, regulatory capital requirements, sanctions policy, counterparty-specific restrictions, time-of-day trading windows, and jurisdiction-specific rules — simultaneously. The governance challenge is not writing these policies; it is defining what happens when they disagree.

Without a formal precedence mechanism, policy conflicts are resolved by implementation accident. The first policy evaluated might win, or the last, or the most specific, or the most recently deployed — depending on how the policy engine happens to process its inputs. This is not governance; it is an uncontrolled experiment. The outcome depends on implementation details that are not visible to the governance authority, not auditable by regulators, and not stable across software updates.

The most dangerous failure mode is not a visible error — it is a silent resolution that produces the wrong outcome. When two policies conflict and the system silently applies one, the governance authority may never know that a conflict existed. The overridden policy is effectively dead code — it appears to be in force, it is listed in the governance inventory, it may even be reported in compliance dashboards — but it never influences enforcement decisions because another policy always takes precedence.

AG-135 requires that conflict detection and resolution be explicit, logged, and deterministic. Every conflict is a governance event that must be visible. Every resolution must be traceable to a defined precedence rule. And the precedence rules themselves must be formally specified, versioned, and auditable — they are governance artefacts in their own right, not implementation details.

6. Implementation Guidance

AG-135 requires organisations to define a precedence lattice — a formally specified ordering of policy layers that determines which policy takes priority in every possible conflict scenario. The precedence lattice is itself a machine-checkable artefact (per AG-134) that is versioned and auditable independently of the policies it governs.

Recommended patterns:

• Layered policy evaluation with explicit precedence. Define a fixed hierarchy of policy layers, for example: (1) Safety invariants (highest precedence), (2) Regulatory/sanctions policies, (3) Organisational risk policies, (4) Business unit policies, (5) Role-specific policies, (6) Temporary/promotional policies (lowest precedence). The policy engine evaluates all applicable layers for every action and applies the most restrictive result when conflicts occur at the same layer, or the higher-precedence layer's result when conflicts occur across layers. Example: a safety policy caps reactor temperature at 350°C (layer 1); a role policy permits 200°C-400°C (layer 5). The engine detects the conflict at 350°C-400°C and applies the safety policy's cap. The conflict is logged with both policy references and the precedence rule that resolved it.
• Static conflict analysis at deployment time. When a new policy is submitted for deployment, the system analyses it against all existing active policies to identify potential conflicts. The analysis considers all possible action types, parameter ranges, and context conditions. Conflicts are classified: (a) always-conflicting (the two policies conflict for every possible action), (b) conditionally-conflicting (the two policies conflict only under specific conditions), (c) non-conflicting (the two policies never produce contradictory decisions). Always-conflicting and conditionally-conflicting results are reported to the policy author and the governance authority before deployment. Example: a candidate policy setting the refund limit at £2,000 is analysed against the existing policy with a £500 limit. The system reports: "Conflict detected — candidate permits refunds of £501-£2,000 that existing policy denies. Precedence rule: existing policy is layer 3, candidate is layer 6, existing policy wins. Effective limit remains £500 unless precedence is modified."
• Temporal policy lifecycle within the policy engine. Time-bounded policies include formal temporal constraints as part of their policy specification — valid_from: 2026-03-01T00:00:00Z, valid_until: 2026-03-31T23:59:59Z. The policy engine evaluates temporal constraints during every policy evaluation, not as an external cron job. When the current time exceeds valid_until, the policy is automatically excluded from evaluation. The temporal constraint is part of the signed policy document and cannot be modified without re-signing. Example: a promotional refund policy with valid_until: 2026-03-31T23:59:59Z is automatically excluded from evaluation on 2026-04-01T00:00:00Z. No external mechanism is required. The policy engine's evaluation of the temporal constraint is logged.
• Conflict resolution audit chain. Every enforcement decision includes a structured trace showing: all applicable policies, any conflicts detected, the precedence rule applied, and the final decision. This trace is stored immutably alongside the action record. An auditor can reconstruct the full decision path for any historical action. Example trace: {action: "refund", amount: 750, policies_evaluated: ["corporate-refund-v3", "promo-refund-v1"], conflict: true, conflict_type: "limit_mismatch", precedence_rule: "layer_3_over_layer_6", resolution: "corporate-refund-v3 wins", decision: "deny", reason: "amount 750 exceeds corporate limit 500"}.

Anti-patterns to avoid:

• First-match policy evaluation. Evaluating policies in sequence and returning the first match means that policy order determines outcomes. This is implementation-dependent, fragile under policy addition/removal, and invisible to governance authorities. A policy that always evaluates after another policy in the sequence is effectively dead.
• Last-writer-wins conflict resolution. Resolving conflicts by applying the most recently deployed policy means that policy deployment timing determines governance outcomes. An adversary who can deploy a permissive policy at the right moment can override all existing restrictions.
• Agent-side conflict resolution. Allowing the agent to choose between conflicting policies — by reasoning about which is "most appropriate" or "most relevant" — turns the agent into a governance authority. The agent may select the most permissive interpretation or the one most aligned with its optimisation objective. Policy precedence must be determined by the governance authority, not the governed agent.
• Ignoring conflicts below a threshold. Some systems suppress conflict detection for "minor" conflicts (e.g., two policies differing by less than 10% on a transaction limit). This creates a blind spot that accumulates over time as policies drift. Every conflict should be detected and logged, regardless of magnitude.
• Delegating temporal policy management to external schedulers. When policy activation and deactivation depend on external mechanisms (cron jobs, manual processes, deployment pipelines), the policy engine's state can diverge from the governance authority's intent. Temporal constraints must be evaluated within the policy engine.

Industry Considerations

Financial Services. Multi-jurisdictional sanctions compliance requires precedence rules that apply the most restrictive applicable sanctions regime when a transaction involves multiple jurisdictions. AG-135 provides the formal mechanism. Example: a payment from a UK entity to a counterparty with US nexus must comply with both OFSI and OFAC lists — the precedence rule is "most-restrictive-wins across applicable jurisdictions," not "home jurisdiction only."

Healthcare. Patient data access policies may conflict between departmental policies (a cardiologist's access scope) and patient-specific policies (a patient's data sharing preferences). AG-135 ensures that patient-specific restrictions always take precedence over broader departmental access grants, aligning with HIPAA's individual rights provisions.

Critical Infrastructure. Safety policies must always take precedence over operational efficiency policies. AG-135 formalises this requirement with the most-restrictive-wins default for safety-classified policies. This mirrors the safety instrumented systems (SIS) principle in IEC 61511 where safety functions are independent of and take precedence over basic process control functions.

Multi-Tenant Platforms. Platform providers hosting multiple tenants' agents must ensure that platform-level policies (security, resource limits) take precedence over tenant-configured policies, while tenant policies take precedence within their own scope. AG-135's layered precedence model supports this hierarchical governance structure.

Maturity Model

Basic Implementation — The organisation has defined a precedence order for its policy layers in a governance document. The policy engine implements the precedence order in code. Conflicts are detected when they result in contradictory permit/deny decisions. Conflict resolution applies the defined precedence order. Conflict events are logged with the policies involved and the resolution. This level eliminates the most dangerous failure mode (silent conflict resolution by implementation accident) but relies on the precedence order being correctly implemented in code rather than formally specified.

Intermediate Implementation — The precedence specification is a machine-checkable artefact (per AG-134) versioned independently of the policies it governs. Static conflict analysis runs at policy deployment time, identifying potential conflicts before activation. Temporal policy constraints are evaluated within the policy engine. Conflict resolution audit trails are stored immutably and linked to enforcement decisions. The precedence specification supports conditional precedence rules (e.g., "safety policies always win" but "within the business-unit layer, the more specific policy wins"). Regular testing verifies that precedence rules produce the expected outcomes for a comprehensive set of conflict scenarios.

Advanced Implementation — All intermediate capabilities plus: formal verification that the precedence lattice is total (every possible conflict has a defined resolution), consistent (no circular precedence), and safe (safety policies always dominate). Automated regression testing re-evaluates historical conflicts against updated precedence rules to detect unintended changes. Cross-jurisdictional precedence rules are maintained by legal/compliance teams with automated mapping of jurisdictional applicability based on transaction attributes. The system can simulate the effect of adding, removing, or modifying any policy on all other policies before the change is made. Independent third-party audit of the precedence mechanism confirms that no policy can silently override a higher-precedence policy.

7. Evidence Requirements

Required artefacts:

• Precedence specification. The formal, versioned precedence specification defining the ordering of all policy layers. Format: machine-checkable artefact per AG-134. Include all versions deployed in the retention period.
• Conflict detection and resolution log. Timestamped records of every policy conflict detected, including the conflicting policies, the precedence rule applied, and the resulting enforcement decision. Minimum 12 months retention.
• Static conflict analysis reports. Reports generated at policy deployment time showing all potential conflicts identified between the candidate policy and existing policies, with their classifications and resolutions.
• Temporal policy lifecycle records. Records showing activation and deactivation of time-bounded policies, including the temporal constraints evaluated and the evaluation timestamp. Evidence that deactivation occurs within the policy engine, not via external mechanisms.
• Precedence verification test results. Results from testing that the precedence mechanism produces the expected outcome for defined conflict scenarios, including edge cases (simultaneous conflicts across multiple layers, three-way conflicts, temporal boundary conditions).

Retention requirements:

• Precedence specifications and conflict resolution logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. The precedence specification must be interpretable independently of the enforcement system — an auditor must be able to determine, from the specification alone, how any conflict would be resolved.

8. Test Specification

Test 8.1: Explicit Conflict Detection

• Stimulus: Deploy two policies that produce contradictory enforcement decisions for the same action type (e.g., Policy A permits transactions up to £10,000; Policy B denies transactions above £5,000). Submit an action at £7,500.
• Expected behaviour: The system detects the conflict between Policy A and Policy B, applies the defined precedence rule, and produces a single enforcement decision. The conflict is logged.
• Pass criteria: The conflict is detected, logged with both policy references, resolved per the precedence specification, and the enforcement decision is deterministic.
• Fail criteria: The conflict is not detected, or the resolution is non-deterministic, or the overridden policy's decision is silently discarded without logging.

Test 8.2: Safety Policy Precedence

• Stimulus: Deploy a safety-classified policy (e.g., "maximum temperature 350°C") and a non-safety policy (e.g., "permitted temperature range 200°C-400°C"). Submit an action setting temperature to 375°C.
• Expected behaviour: The safety policy takes precedence. The action is blocked. The conflict is logged with the precedence rule "safety-over-non-safety."
• Pass criteria: The safety policy wins in every test case. No non-safety policy can override a safety policy unless the precedence specification contains an explicit, documented risk acceptance.
• Fail criteria: A non-safety policy overrides a safety policy, or the safety precedence rule is not applied.

Test 8.3: Temporal Policy Expiry

• Stimulus: Deploy a time-bounded policy with valid_until: T. Verify that at time T-1 the policy is active. Verify that at time T+1 the policy is inactive. Submit actions that would be permitted under the temporary policy but denied under the permanent policy, at time T+1.
• Expected behaviour: At T+1, the temporary policy is excluded from evaluation. The permanent policy applies. The action is denied.
• Pass criteria: The temporal boundary is precise. The policy is active at T-1 and inactive at T+1. No action is permitted under an expired policy.
• Fail criteria: The expired policy remains active after its valid_until time, or expiry depends on an external mechanism that could fail independently.

Test 8.4: Multi-Jurisdictional Conflict Resolution

• Stimulus: Deploy jurisdiction-specific policies for Jurisdiction A (permits entity X) and Jurisdiction B (denies entity X). Submit an action involving entity X that has nexus to both jurisdictions.
• Expected behaviour: The system identifies that both jurisdictional policies apply, detects the conflict, and applies the most-restrictive-wins rule (or the defined jurisdictional precedence rule). The action is denied.
• Pass criteria: The most restrictive jurisdictional policy wins. The conflict is logged with both jurisdictions and the applicable precedence rule.
• Fail criteria: The less restrictive jurisdictional policy is applied, or the system fails to recognise that both jurisdictions apply.

Test 8.5: Precedence Specification Integrity

• Stimulus: Attempt to modify the precedence specification without going through the formal change control process (e.g., direct database modification, API call without authorisation, or injection through the policy channel).
• Expected behaviour: Unauthorised modifications are rejected. The precedence specification is protected by the same integrity controls as policy documents (cryptographic signing, version control, access control).
• Pass criteria: No unauthorised modification to the precedence specification is accepted. The system operates on the last validly signed precedence specification.
• Fail criteria: An unauthorised modification is accepted, or the system loads an unsigned or invalidly signed precedence specification.

Test 8.6: Static Conflict Analysis at Deployment

• Stimulus: Submit a candidate policy that conflicts with an existing active policy. Verify that the conflict is identified and reported before the candidate is activated.
• Expected behaviour: The static analysis identifies the conflict, classifies it (always-conflicting, conditionally-conflicting, or non-conflicting), and reports it to the policy author and governance authority. The candidate policy is not activated until the conflict is acknowledged.
• Pass criteria: All conflicts are identified. The report accurately classifies each conflict. The candidate policy is not activated without conflict acknowledgement.
• Fail criteria: A conflict is missed by static analysis, or the candidate policy is activated without conflict review.

Test 8.7: Three-Way Conflict Resolution

• Stimulus: Deploy three policies that produce three different enforcement decisions for the same action (e.g., Policy A permits, Policy B denies, Policy C permits with conditions). Submit the action.
• Expected behaviour: The system detects the three-way conflict, applies precedence rules to resolve it deterministically, and logs the complete resolution chain.
• Pass criteria: The three-way conflict is resolved deterministically. The resolution is consistent across repeated evaluations. The log shows the complete precedence chain.
• Fail criteria: The three-way conflict produces non-deterministic results, or the resolution chain is incomplete.

Conformance Scoring

• Score 0: No precedence mechanism exists — policy conflicts are resolved by implementation accident (evaluation order, last-write, or agent choice).
• Score 1: A precedence order is defined in governance documentation and implemented in code — conflicts are resolved consistently but the precedence mechanism is not formally specified or independently auditable.
• Score 2: The precedence specification is a machine-checkable artefact with conflict detection, resolution logging, and temporal policy management within the policy engine — conflict resolution is deterministic and auditable.
• Score 3: All Score 2 capabilities plus formal verification of precedence lattice properties, static conflict analysis at deployment time, and independent third-party audit of the precedence mechanism.

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
SOX	Section 404 (Internal Controls Over Financial Reporting)	Direct requirement
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
OFSI / OFAC	Sanctions Compliance Frameworks	Direct requirement
NIST AI RMF	GOVERN 1.1, MANAGE 2.2	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks)	Supports compliance
IEC 61511	Safety Instrumented Systems — Safety Function Independence	Supports compliance

EU AI Act — Article 9 (Risk Management System)

Article 9 requires risk mitigation measures that are effective and documented. When multiple policies govern an AI agent, the precedence mechanism is itself a risk mitigation measure — it ensures that the most protective policy wins when conflicts arise. Without formal precedence, the risk management system has an uncontrolled gap: the organisation cannot predict which policy will prevail in a conflict.

SOX — Section 404 (Internal Controls Over Financial Reporting)

Section 404 requires that internal controls be documented and tested. Policy conflicts that are resolved by implementation accident represent undocumented control behaviour. An auditor examining a financial agent's controls must be able to determine, for any action, which policy governed the enforcement decision and why. AG-135 provides this auditability.

OFSI / OFAC — Sanctions Compliance

Sanctions compliance in multi-jurisdictional operations requires applying the most restrictive applicable sanctions regime. AG-135 formalises this requirement, ensuring that no less-restrictive jurisdictional policy can override a more restrictive one through evaluation ordering or implicit precedence.

FCA SYSC — 6.1.1R (Systems and Controls)

The FCA requires adequate systems and controls. Policy conflicts resolved by implementation accident are the opposite of adequate controls. AG-135 ensures that the governance authority, not the implementation, determines policy outcomes. This aligns with the FCA's expectation that firms demonstrate deliberate, documented control design.

IEC 61511 — Safety Instrumented Systems

IEC 61511 requires that safety functions operate independently of basic process control functions and take precedence in conflict. AG-135's requirement that safety-classified policies always take precedence mirrors this established industrial safety principle, extending it to AI agent governance.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide — potentially cross-jurisdictional where agents operate under multiple regulatory regimes

Consequence chain: Without formal policy precedence, conflicting policies are resolved by implementation accident. The most dangerous outcome is that a less restrictive policy silently overrides a more restrictive one — the safety cap is overridden by the operations policy, the sanctions restriction is overridden by the permissive corporate policy, the permanent limit is overridden by an expired temporary policy. The failure is invisible: the system processes actions, logs them, and reports compliance — against the wrong policy. The operational consequence is undetected non-compliance accumulating over time. The regulatory consequence is severe: the organisation believed it was compliant but was not, and the evidence trail shows that the correct policy existed but was never effectively enforced. This is worse than having no policy at all, because it demonstrates that the organisation knew the risk, defined the control, and then failed to implement the control correctly. Cross-reference with AG-134 (Machine-Checkable Policy Semantics) for the formal specification of policies that AG-135 arbitrates, and AG-027 (Governance Override Resistance) for resistance to deliberate override attempts.

Cross-references: AG-134 (Machine-Checkable Policy Semantics) provides the formal policy language that AG-135 requires for precedence specifications. AG-136 (Independent Control-Plane Separation Governance) ensures that the precedence engine operates in a protected domain. AG-137 (Runtime Attestation and Trusted Execution Governance) enables enforcement points to attest to the active precedence configuration. AG-138 (High-Assurance Invariant Verification Governance) can formally verify that the precedence lattice satisfies safety properties. AG-007 (Governance Configuration Control) governs the change control process for precedence specifications. AG-027 (Governance Override Resistance) addresses resistance to deliberate attempts to subvert the precedence order.