The Arbitration Patterns
When two governed agents disagree, something has to decide. This paper shows how to design that something. | A companion to Articles 7-9
Editor’s note: This companion paper builds on the authority graph and composition contracts established in The Unit of Authority, Authority Composition, and the enforcement argument in When Boundaries Must Decide. It defines what happens when two governed agents disagree. The Authority Graph Formalization companion defines the structure. This companion defines the conflict resolution mechanisms that operate within it. An instructional tutorial walks through the reference implementation step by step.
The Authority Graph Formalization defined the structure: authority units, delegation edges, composition contracts. The composition contract specifies what happens when domains disagree: halt, deny, or resolve through precedence. But the contract is a specification, not a mechanism.
When the arbitration call fires, something must evaluate the conflict and produce a decision. This paper defines that something.
The reader who finishes this paper will have the arbitration patterns, the escalation architecture, and the governance maturation model needed to handle every class of conflict their composition contracts will encounter. A reference implementation exists: the Agent Fabric governance engine implements all four patterns as a deterministic Python package, architecturally separate from the agents it governs. The patterns described here are not theoretical. They are deployed. Practitioners who want to step through the code can find an instructional tutorial that walks through each pattern with the implementation.
Four arbitration patterns
Four patterns, each resolving a distinct class of conflict. Each is evaluated deterministically. Each produces a legibility record.
Pattern 1: Scope-based arbitration. Two authority units claim jurisdiction over the same action. The unit with the most specific scope governs: specific statute before general law. Specificity is measured by the number of conditions and limits in the scope tuple; the unit with more constraints is the tighter fit. This pattern runs within a single domain, before any composition contract evaluation. It resolves many conflicts because overlaps frequently involve one unit with a broad scope and another with a narrow, specific scope covering the same decision class.
Pattern 2: Priority arbitration. Both units have valid, specific scope and their evaluations produce conflicting results. One permits. The other denies. The composition contract’s authority_precedence field names which party governs for this interaction class. Priority is not hierarchy. It is contextual ordering: Domain A may have priority over transaction limits while Domain B has priority over data handling. The ordering is encoded in the contract and evaluated deterministically. In XACML terms, this is the first-applicable combining algorithm: evaluate in order, first match decides.
Pattern 3: Conjunction arbitration. Both authority units must permit before the action proceeds. If either denies, the action is blocked. This is the default for independently sovereign domains where neither has agreed to defer. Practitioners building governance for autonomous systems have already deployed this pattern: each system maintains its own policy gate, both must pass, composition is gate-to-gate. “Independence first. Composition follows.” In XACML terms, this is deny-overrides: any denial blocks regardless of other permits. What conjunction sacrifices in throughput it gains in governance. No action proceeds without the explicit consent of every sovereign domain involved.
Choosing between priority and conjunction. The contract author decides at design time. Use conjunction (Pattern 3) when neither domain has agreed to defer; both are independently sovereign and both must consent. This is the conservative default. Use priority (Pattern 2) when one domain’s governance is categorically more relevant for a specific interaction class: the fraud domain has priority over risk decisions, the compliance domain has priority over regulatory decisions, even when those decisions affect the payment domain’s scope. Priority is not a blanket ordering. It is scoped to an interaction class. A single composition contract may use conjunction for one class and priority for another.
Pattern 4: State-aware arbitration. The conflict depends on runtime state that the static authority graph does not capture. One domain permits based on its current state; the other would deny based on information the first domain does not have. State-aware arbitration evaluates the conflict against shared state, or the absence of shared state. When state is unconfirmed, monotonic reduction fires: the engine halts immediately. It does not permit under uncertainty.
The implementation of Pattern 4 is deliberately simple. The governance engine does not interpret state. It observes a signal: if any context value is flagged as unconfirmed by the state provider, the engine halts before evaluating any substantive pattern. The engine is decoupled from domain knowledge. The state provider signals confirmation status. The engine acts on the signal.
This implements the convergence-before-propagation requirement: if the state under which authority would be evaluated has drifted outside its admissible window, the arbitration layer must verify convergence before resolving. “If convergence sits outside the authority layer, you’ve already lost the guarantee.”
