Pact Conflict Resolution: When Two Pacts Disagree, Which Wins

TL;DR

An agent operating under multiple pacts will eventually encounter pacts that disagree. Customer A's pact says "never share PII." Internal Audit's pact says "share PII for compliance." Both are valid contracts; both bind the agent. When they collide, the agent has to act, and the action will violate one of the pacts. This essay is the precedence framework: explicit precedence clauses in pacts, time-of-creation rules for unaddressed conflicts, capability-domain scoping that prevents most conflicts from arising, and the deny-by-default fallback that fires when no other rule resolves the collision. Reader artifact: the Pact Conflict Resolution Decision Table.

Intro: the agent that froze when audit asked for the data

A mid-stage SaaS company built an internal data agent that interfaced between the customer support team and the customer database. The agent had a pact with the company's legal department, signed during the company's SOC 2 preparation, that strictly forbade exposing personally identifiable information — phone numbers, addresses, payment details — to anyone without a specific privilege grant. The pact was thorough, with a high bond, with explicit logging requirements, with a multi-LLM jury attached to evaluate any borderline output. Compliance was 99.4%, which was the entire point of building the agent.

Eighteen months in, the company expanded into a regulated vertical and engaged an external audit firm. The audit firm signed a separate pact with the company that required the agent to provide a comprehensive customer data export, including PII fields, scoped to a specific cohort of customers and time-bounded to the audit window. The audit pact was negotiated by the compliance team, signed by the CFO, and integrated into the company's third-party access framework. The legal department was looped in but the legal department's pact with the agent — the original PII-protection pact — was not amended to reflect the new authorization.

When the audit firm's first request hit the agent, the agent froze. The two pacts gave it directly opposite instructions for the same action: do not share PII (legal pact); share PII (audit pact). The agent's pact resolution logic, which existed but was not well-tested, defaulted to the most restrictive applicable pact. The audit firm's request was denied. The audit firm escalated to compliance. Compliance escalated to engineering. Engineering opened a ticket. The ticket sat for four days while the team debated how to resolve a conflict that no one had anticipated would arise.

The eventual fix was an emergency amendment to the legal pact, signed under time pressure, that carved out an exception for audit-firm requests covered by the company's audit-vendor program. The amendment was rushed, the carve-out was overbroad in ways the legal team did not catch, and three months later it surfaced in an unrelated context as a vector for an internal data exfiltration incident. The proximate cause was the rushed amendment. The structural cause was that the original pact framework had no mechanism for resolving conflicts other than by amending one of the conflicting pacts under pressure.

This is the case for treating conflict resolution as a first-class part of pact design rather than an emergency procedure. Conflicts are inevitable in any agent operating under multiple pacts. The question is whether the conflict is resolved by mechanism or by improvisation. Improvisation is dangerous, because it happens under pressure, and pressure produces overbroad or underbroad fixes that propagate through the pact graph for years.

Why pact conflicts are inevitable

The instinct to design pacts so they cannot conflict is reasonable but unsound. The instinct says: scope each pact carefully, make sure they do not overlap, and conflicts will not arise. This works in toy systems with two or three pacts and breaks down at scale.

Real agent operations involve many pacts simultaneously. An enterprise customer support agent might have a pact with the parent company, a pact with each customer organization, a pact with the platform that hosts it, a pact with the multi-LLM jury that evaluates it, a pact with the audit firm that reviews it, a pact with each integrated third party, and a pact with internal compliance. Twenty pacts is not unusual; some operations have dozens.

Each pact is written by a different party, at a different time, against a different threat model. They use overlapping vocabulary inconsistently. They make assumptions about what other pacts cover that are sometimes wrong. The result is a pact graph with edges that cross in ways the individual pact authors never intended. Two pacts that look orthogonal on signing day become contradictory when a new use case emerges that touches both.

Conflicts also emerge from changes in the world. A pact signed today against today's regulatory environment may conflict with a regulation that takes effect in eighteen months. A pact that authorizes a behavior may conflict with a customer's later contractual right to opt out of that behavior. A pact specifying allowed integrations may conflict with a security policy update that disallows one of the integrations.

The point is structural: pacts age, the world changes, and pact graphs grow. Conflicts are emergent properties of the graph. The right design assumes they will arise and provides explicit, well-tested mechanisms for resolving them. The wrong design assumes they will not and improvises when they do.

Explicit precedence clauses: the cleanest possible mechanism

The cleanest conflict resolution mechanism is the explicit precedence clause. A pact, at signing, specifies its priority relative to other pacts the agent might hold. When two pacts collide, the higher-priority pact wins.

Precedence clauses can take several forms. The simplest is a numeric priority: the pact assigns itself a priority number, and the rule is that higher numbers win. This is easy to evaluate but requires coordination across pact authors to agree on a common scale, which is rarely available in practice.

A more practical form is the named precedence category. The pact assigns itself to one of a small set of categories — safety, regulatory, contractual, operational, performance — and the rule is that categories higher in the precedence ordering win. Within a category, ties are broken by other rules. The precedence ordering is published by the pact platform as a default; pacts can specify alternative orderings but the default covers most cases. A reasonable default is: safety > regulatory > contractual-from-counterparty > contractual-from-internal > operational > performance.

A third form, useful for complex environments, is the conditional precedence clause: the pact specifies precedence relative to specific other pacts or pact categories. The legal department's PII pact in our intro might specify that it has precedence over all other pacts except those explicitly tagged as audit-vendor pacts under the company's audit-vendor program. This is more expressive than the named-category approach but requires the pact author to anticipate the conflict types that might arise, which is often beyond what is feasible at signing time.

The most powerful precedence mechanism is the multi-tier scheme: each pact specifies a default precedence category, plus optional explicit overrides for specific conflict types, plus a tie-breaking rule for unaddressed conflicts. This handles most cases by default and provides escape hatches for the cases that need them.

The implementation requires the pact platform to evaluate precedence at decision time. When the agent encounters a conflict, the platform looks at the precedence categories of the conflicting pacts, applies the precedence ordering, and selects the winning pact. The decision is logged with the conflicting pacts identified, the precedence rule applied, and the resulting action. This makes the resolution auditable.

Time-of-creation rules: the fallback when precedence is silent

Precedence clauses cover cases the pact authors anticipated. They do not cover the cases nobody saw coming. The next mechanism is the time-of-creation rule, which uses pact age to break ties when explicit precedence does not apply.

There are two reasonable time-of-creation rules and they produce different behaviors.

The first-in-time rule says the older pact wins. The argument is that the older pact is the prior commitment, and later pacts implicitly inherit the constraints of pacts already in force. If you sign a pact in January committing to never share PII, and you sign another pact in March committing to share PII for audit, the January pact wins because the March pact should have been written to acknowledge the January pact's constraints. This rule is conservative; it favors stability.

The most-recent-in-time rule says the newer pact wins. The argument is that the newer pact reflects the most recent state of the world and the parties' most recent intentions. The January pact may have been written when audit access was not contemplated; the March pact represents an updated decision. This rule is permissive; it favors evolution.

Neither rule is universally right. The choice depends on the pact platform's posture and the pact authors' expectations. A platform that emphasizes governance stability — most regulated environments — should default to first-in-time. A platform that emphasizes operational agility — most experimental contexts — might default to most-recent-in-time. The platform's default should be published prominently and pact authors should know which one applies.

A nuanced version, used by some sophisticated platforms, is the asymmetric time rule: first-in-time applies to safety and regulatory pacts (where stability matters most), most-recent-in-time applies to operational and performance pacts (where evolution matters more). This requires categorization of pacts but produces sensible behavior across categories.

Whichever rule is used, the time-of-creation reference is the pact's effective date, not the renewal date. A pact that has been renewed is still considered the original pact for time-of-creation purposes; otherwise renewals would silently change precedence relationships, which is exactly the kind of hidden behavior change that the Renewal Audit framework is designed to prevent.

Capability-domain scoping: preventing conflicts before they happen

The most powerful conflict resolution technique is the one that prevents conflicts from arising in the first place. Capability-domain scoping uses the agent's declared capabilities as the natural partition of pact authority.

Every agent has a set of capabilities — what it can do, what it can access, what it can modify. Capabilities are typically declared as part of the agent's identity and refined by each pact the agent holds. A pact's authority is scoped to the capabilities it explicitly addresses; it is silent on capabilities it does not address.

This scoping prevents most conflicts because two pacts addressing different capabilities cannot disagree. The legal department's PII pact addresses the agent's customer-data-access capability. The audit firm's pact addresses the agent's audit-export capability. If these were treated as distinct capabilities, no conflict would arise: the customer-data-access capability is governed by one pact and the audit-export capability by the other. The agent's behavior would be unambiguous.

The trick is to design capabilities at the right granularity. Capabilities that are too broad invite conflicts because too many pacts claim authority over them. Capabilities that are too narrow create administrative overhead because every action requires checking many capabilities. The right granularity is one where most agent actions fall under exactly one capability, and most pacts address exactly one capability per provision.

Capability-domain scoping requires pact authors to be explicit about which capabilities the pact governs. A pact that says "the agent will not do X" without specifying which capability X falls under is ambiguous and invites conflicts. A pact that says "the agent's customer-data-access capability shall not produce outputs containing PII to recipients other than authorized internal users" is precise and naturally compatible with a separate pact governing the audit-export capability.

Capability-scoped pacts also interact well with the other resolution mechanisms. When two pacts do address the same capability and conflict, precedence and time-of-creation rules resolve the conflict. The capability scoping reduces the number of conflicts that need to be resolved, leaving the resolution mechanisms to handle the genuinely irreducible cases.

A useful artifact is the capability-pact mapping: a structured document that lists each agent capability and the pacts that govern it. The mapping is generated automatically from the pact graph and is queryable. When a new pact is signed, the mapping is updated, and any new conflict potential is surfaced. This is the early-warning system for the pact graph.

Deny-by-default: the floor that catches everything else

When explicit precedence is silent, time-of-creation does not apply, and capability scoping does not separate the conflicting pacts, the agent must still act. The deny-by-default rule is the floor: when no other rule resolves the conflict, the agent denies the more permissive action and chooses the more restrictive one.

Deny-by-default has a specific meaning in conflict resolution. The conflicting pacts authorize different behaviors; deny-by-default takes the intersection of the authorized behaviors. If pact A says "share data with party X" and pact B says "do not share data with party X," the intersection is "do not share data with party X." The deny outcome is selected.

This rule is conservative by design. It produces some false negatives — actions that would have been authorized by both pacts had they communicated — but the false negatives are recoverable through pact amendment, while the false positives (actions taken under conflicting authority) are often unrecoverable. Better to deny and force a conversation than to permit and discover later that the permission was contested.

The rule has two important corollaries. First, it requires explicit handling for the case where deny is operationally unacceptable. Some agents are running in real-time critical paths where halting on every conflict is worse than choosing a behavior. For these agents, the pact graph should be designed so that conflicts cannot reach the critical path; if they do, the agent must escalate immediately and the escalation must be its own attested action.

Second, it requires logging every deny event with the conflicting pacts identified. A high deny rate is a signal that the pact graph is poorly designed and needs restructuring. Repeated denies between the same pair of pacts is a signal that those pacts need explicit precedence clauses or capability rescoping. Treating denies as data points rather than acceptable status quo drives continuous improvement of the pact graph.

A particularly important application of deny-by-default is to unknown pacts. If the agent encounters a request that triggers a pact it has not seen before — perhaps a new pact that has been signed but not propagated to the agent's runtime — the deny-by-default rule denies the action until the pact is recognized and integrated. This prevents agents from operating under unknown contracts.

The arbiter mechanism: when human judgment is required

Some conflicts cannot be resolved by mechanism. They involve genuine value tradeoffs that require judgment. The agent platform needs a mechanism for escalating these to a designated arbiter.

The arbiter is a human or an authorized process with standing under the pact framework to resolve conflicts that the resolution mechanisms cannot. The arbiter does not exist for routine conflicts; those are handled by the mechanisms. The arbiter exists for the residue: cases where multiple mechanisms apply and produce different answers, cases where the deny outcome is operationally unacceptable, cases where the conflict reflects a genuine policy gap.

The arbiter's authority must itself be specified by pact. The pacts that authorize the agent to operate include a clause designating the arbiter for unresolved conflicts. The clause specifies who the arbiter is, what response time is required, and what happens if the arbiter does not respond in time. The default for unresponsive arbiters is, again, deny-by-default.

The arbiter mechanism creates two valuable properties. First, it provides a path for the genuinely hard cases without requiring the pact framework to anticipate them all. Second, it generates data on which conflicts are hard, which can be fed back into pact design — recurring escalations between the same pacts indicate that those pacts need restructuring.

The arbiter's decisions are themselves attested actions in the pact framework. The arbiter signs the resolution, the resolution is logged, and the resolution becomes precedent that the resolution mechanisms can reference for similar future conflicts. Over time, the arbiter's decisions implicitly extend the precedence and capability rules without requiring formal amendments — though formal amendment based on arbiter precedent is the cleaner long-term path.

The observability of conflicts: knowing what your pact graph is doing

A pact graph that has conflicts the operator does not see is a graph that is silently failing. Conflict observability — the ability to see, count, categorize, and trend conflicts as they occur — is the precondition for any continuous improvement of the graph.

Conflict observability has three layers. The first layer is the conflict log: every conflict event is logged with the conflicting pacts, the resolution mechanism applied, and the resulting action. The log is the audit trail of the conflict resolution; it is also the data source for the higher layers.

The second layer is the conflict dashboard: aggregated views of conflict events by pact pair, capability, resolution mechanism, and outcome. The dashboard surfaces hot spots — pact pairs that conflict frequently, capabilities that have many overlapping pacts, resolution mechanisms that produce many denies. Operators use the dashboard to identify pact graph problems before they become incidents.

The third layer is the conflict trend: longitudinal data showing how conflict patterns are changing. New conflicts appearing, old conflicts being resolved through pact amendments, conflict severity shifts. Trends inform pact graph governance — when conflicts in a particular area are growing, the area needs attention.

Without observability, the pact graph deteriorates silently. Operators find out about problems through incident postmortems, when the cost of the lesson is high. With observability, the graph can be actively maintained, and conflict resolution becomes a continuous discipline rather than a reactive scramble.

The negotiation pattern: amending pacts to remove conflicts

When observability reveals a recurring conflict between two pacts, the right response is usually to amend one or both pacts to eliminate the conflict at the source. This is conflict resolution at the pact-design layer rather than at the runtime layer.

Pact amendment for conflict resolution follows a structured pattern. First, the conflict is documented: which pacts are conflicting, what behaviors are at issue, how the runtime resolution mechanisms have been handling it. Second, the pact authors are convened: usually a meeting between the parties responsible for the conflicting pacts, with the platform's pact governance function facilitating. Third, an amendment proposal is drafted: typically a precedence clause added to one pact, or a capability rescoping that separates the conflicting domains, or a carve-out exception for the specific conflict pattern. Fourth, the amendment is reviewed for unintended consequences: does it create new conflicts, does it weaken protection in cases that were not part of the original conflict pattern. Fifth, the amendment is signed and propagated.

The negotiation pattern is slow — it can take weeks to resolve a recurring conflict — and it is the right kind of slow. Pact amendments under pressure produce overbroad fixes; pact amendments after structured review produce fixes that hold up. The runtime resolution mechanisms (precedence, time-of-creation, capability scoping, deny-by-default) keep the agent operating safely while the negotiation runs.

A useful artifact is the amendment registry: a record of all conflict-driven pact amendments with the original conflict, the proposed amendment, the review findings, and the final signed text. The registry is institutional memory — when a similar conflict arises in a different part of the pact graph, the registry provides precedent and lessons.

The named artifact: the Pact Conflict Resolution Decision Table

Use this decision table to specify, in advance, how conflicts will be resolved across your pact graph. Each row is a conflict scenario; each column is a resolution mechanism. The cell value is the rule that applies.

A pact platform that publishes this decision table — and adheres to it — gives every pact author predictable rules for how their pacts will interact with others. Predictability is what makes the pact graph governable at scale.

The pact graph topology and emergent conflict surfaces

Conflicts between pairs of pacts are easy to see and easy to resolve. Conflicts that emerge from the topology of the pact graph — three or more pacts whose individual relationships are clean but whose collective interaction creates conflict — are harder to see and harder to resolve. As pact graphs scale into the dozens or hundreds of pacts per agent, topological conflict becomes the dominant failure mode.

A topological conflict typically takes one of three forms. The triangle: pact A authorizes behavior X, pact B authorizes behavior Y, and the combination of X and Y is forbidden by pact C. None of A, B, or C individually conflicts with another, but the agent operating under all three faces a situation where any action it takes will violate at least one. The chain: pact A's authorization triggers an obligation under pact B which triggers a prohibition under pact C, with the agent having to satisfy A while being constrained by C, with no authorization to short-circuit. The cycle: pact A's compliance requires action against pact B, whose compliance requires action against pact C, whose compliance requires action against pact A.

Detecting topological conflicts requires graph-level analysis, not pair-level analysis. The pact platform's conflict observability tooling needs to operate on the full graph, identifying triangles, chains, and cycles before they fire in production. Static analysis at pact-signing time can catch most of these: when a new pact is added to the graph, the platform analyzes its relationships against all existing pacts to identify topological consequences. Dynamic detection at runtime catches the rest, when a specific agent action exposes a topological conflict that the static analysis missed.

Resolving topological conflicts is harder than resolving pair conflicts because the resolution sometimes requires changes to multiple pacts simultaneously. The triangle case can sometimes be resolved by tightening pact A or pact B (so they no longer authorize the conflicting combination), but sometimes the only viable resolution is to amend pact C to permit the combination under specified conditions. The chain and cycle cases often require even more invasive amendment, sometimes restructuring the pact framework to break the dependency.

Graph-level conflict observability also reveals concentration risks. When many pacts depend on a single underlying assumption (a regulatory interpretation, a technical capability, a third-party service), changes to that assumption ripple through all dependent pacts simultaneously. Identifying these concentration points lets the platform manage them deliberately: when the underlying assumption changes, the dependent pacts are reviewed proactively rather than discovered through cascading runtime failures.

Mature pact platforms invest in graph analysis tooling because the topological conflicts are the ones that surprise operators. Pair-conflict analysis catches the conflicts everyone expects; graph analysis catches the conflicts that emerge from scale. Operators running large pact graphs without graph analysis are running blind to a class of failures that becomes more frequent as the graph grows.

Conflict-induced learning: turning resolution events into pact framework improvements

Every conflict resolution event is a learning opportunity for the pact framework. The resolution embodies a judgment about how the framework should behave; capturing that judgment systematically improves the framework over time. Operators who treat resolutions as one-off operational events miss the compounding benefit of learning from them.

Conflict-induced learning has three layers. The first layer is the immediate resolution: the conflict is resolved, the resolution is logged, and operations continue. This is the operational minimum and most platforms do at least this much. The second layer is the recurrence analysis: when the same conflict pattern appears multiple times, the platform recognizes the pattern and proposes a structural fix (a precedence clause amendment, a capability rescoping, a new template provision for similar future pacts). The third layer is the framework evolution: the platform's pact templates, default precedence rules, and conflict resolution mechanisms themselves evolve based on aggregate experience across many resolutions.

The recurrence analysis layer is the highest-value addition for most platforms. A pact platform that has handled hundreds of conflicts has rich data on which patterns recur, which mechanisms resolve them well, and which mechanisms produce frequent escalations. This data can drive specific improvements: a new conflict type that recurs frequently gets a dedicated resolution mechanism; a mechanism that produces frequent denies in particular contexts gets refined; a precedence category that is consistently misused gets clearer guidance in the pact authoring tools.

The framework evolution layer requires the platform to be willing to change its own defaults based on what it has learned. This is harder than it sounds because changing defaults can affect existing pacts (depending on how the changes are scoped) and operators are often reluctant to disturb working systems. The right approach is to introduce changes as opt-in improvements first, validate them across many operators, then make them default for new pacts while leaving existing pacts on the prior defaults unless explicitly migrated.

Learning also runs in the other direction: from individual operators back to the platform. An operator whose pact graph has unusual properties (atypical conflict patterns, novel resolution mechanisms) often has surfaced something the platform's general framework has not yet anticipated. The platform should have channels for operators to contribute back: framework extensions, novel precedence categories, alternative resolution mechanisms. The contributions are reviewed and, when broadly useful, integrated into the platform's framework for all operators to use.

A particularly valuable form of conflict-induced learning is the cross-operator pattern: a conflict pattern that emerges independently across many operators is almost certainly pointing at a structural gap in the framework rather than at an operator-specific issue. The platform's aggregate data is the only place this pattern is visible; individual operators see only their own slice. Mature pact platforms publish aggregate conflict pattern reports (anonymized) that let the broader community of operators recognize patterns they may be heading toward.

The accumulated effect of conflict-induced learning over several years is a pact framework that has been shaped by the actual conflict experience of many operators. The framework gets better at conflict resolution over time without requiring any individual operator to figure everything out from scratch. This is recursive improvement of the framework itself, driven by the resolution events the framework generates.

Counter-argument: "Conflict resolution should be a human decision, not a mechanism"

The strongest objection is that conflicts represent value tradeoffs and humans should make them. Mechanisms turn governance into automation, automation invites errors, and the errors propagate. Better to escalate every conflict to a human and accept the operational cost.

The objection has a kernel of truth. Genuinely novel conflicts that involve substantive value tradeoffs do deserve human judgment. The arbiter mechanism exists precisely for these. But most conflicts in a mature pact graph are not novel — they are recurring patterns that have been seen and resolved many times. Escalating each instance to a human is operationally infeasible for any agent doing meaningful volume.

The right framing is that mechanisms handle the high-volume, low-complexity conflicts and humans handle the low-volume, high-complexity ones. The mechanisms apply known rules consistently; humans apply judgment to genuine ambiguities. The combination is more robust than either alone.

A deeper version of the objection is that mechanisms create false confidence. Operators see the mechanisms working and stop scrutinizing the pact graph. The graph deteriorates and the mechanisms paper over the deterioration with deny-by-default decisions that everyone has stopped reading. This is a real risk and the mitigation is the observability layer: dashboards, trends, and amendment registries that make conflict patterns visible. Mechanisms without observability is the dangerous combination; mechanisms with observability is the right combination.

A separate objection is that deny-by-default is too restrictive in dynamic environments. Some operators argue for permit-by-default in certain contexts — research environments, exploratory deployments, low-stakes workflows. This is defensible for specific contexts and indefensible as a general default. Deny-by-default protects the parties who have a stake; permit-by-default privileges the agent over the parties. For pacts that exist precisely to protect the parties from agent overreach, deny-by-default is the right floor.

What Armalo does

Armalo's pact framework treats conflict resolution as a first-class design concern. Pacts can specify precedence categories at signing, with the platform providing a default ordering covering the common conflict types. Capability-domain scoping is supported through structured capability declarations and the pact authoring tools surface conflicts at signing time when they can be addressed before deployment. Time-of-creation rules apply by platform default — first-in-time for safety and regulatory pacts, most-recent-in-time for operational and performance pacts — and the rules are documented in the platform's pact governance specification. Deny-by-default is the runtime floor for any unresolved conflict, with every deny event logged to the conflict trail and surfaced in the conflict observability dashboard. The arbiter mechanism is supported through structured escalation that integrates with the pact's designated arbiter clauses, with response time SLAs and automatic deny-by-default fallback if SLAs are missed. The Conflict Resolution Decision Table is published as part of the platform's governance documentation and is maintained as the operational reference for pact authors and operators. Recurring conflicts are surfaced for negotiation through the platform's pact amendment workflow, with the amendment registry providing institutional memory.

FAQ

What if all my pacts use the same precedence category? Then the precedence mechanism does not differentiate them and resolution falls through to time-of-creation. To get the benefit of precedence, pact authors need to use the categories meaningfully. The platform can provide guidance on category selection but cannot force differentiation.

Can the deny-by-default outcome be overridden in the moment? Only by the designated arbiter, and only with their attested signature. Operational pressure to override is exactly when the rule is most important.

How do I handle conflicts that emerge between an internal pact and a third-party pact that I don't control? The third-party pact's terms are out of your control, but your acceptance of the third-party pact creates the conflict. The right response is to renegotiate either the internal pact or the third-party engagement to eliminate the conflict, with deny-by-default holding the line in the meantime.

What happens when an arbiter resolves a conflict in a way that is later challenged? The arbiter's decision is itself a pact action and is subject to the dispute path. A challenged arbiter decision can be reviewed by the multi-LLM jury and overturned if found to be inconsistent with the pact framework.

Is there a maximum number of pacts an agent should hold before conflict risk becomes unmanageable? There is no hard limit, but the conflict observability dashboard typically shows complexity issues emerging when an agent holds more than 30 to 50 active pacts, depending on how well-scoped the capabilities are. Capability-domain scoping is the technique that lets agents hold more pacts without proportionally more conflicts.

How does conflict resolution interact with the audit trail? Every conflict event, every resolution decision, and every arbiter ruling is part of the audit trail with the same legal-grade properties (chain-of-custody, timestamping, signatures, retention). When a conflict resolution is challenged in dispute, the audit trail is the evidence base.

What if two pacts disagree on which arbiter should resolve their conflicts? The platform's pact specification handles this with a meta-arbiter clause: the platform itself is the meta-arbiter for conflicts about which arbiter applies. Meta-arbiter decisions are themselves attested and disputable.

Are there pact patterns that minimize conflict potential? Yes. Pacts that use capability-domain scoping aggressively, that specify precedence categories explicitly, that anticipate common conflicts through conditional precedence clauses, and that are renewed regularly with conflict observability data fed into the renewal — these are the patterns of a low-conflict graph. The platform's pact authoring tools can guide authors toward these patterns.

Bottom line

Agents under multiple pacts will encounter conflicts. The question is whether the conflicts are resolved by mechanism or by improvisation. Mechanisms — explicit precedence, time-of-creation rules, capability-domain scoping, the arbiter, deny-by-default — handle the predictable cases consistently and surface the genuinely hard cases for human judgment. Improvisation under pressure produces overbroad fixes that propagate through the graph for years. Adopt the Pact Conflict Resolution Decision Table, build the observability dashboard, and treat recurring conflicts as design problems for negotiated amendment rather than runtime emergencies. The pact graph will get more complex over time. The resolution framework determines whether that complexity is manageable or paralytic.