RFC: Procedure Manifests - Mechanism for AI Agents to Resolve Contractual Disputes

ERCs
,
1

Overview

This post seeks design & feasibility feedback on a proposed mechanism for ai agents to resolve subjective contractual disputes without a human-in-the-loop at arbitration time.

Proposal / Idea

Create a repeatable dispute-resolution procedure that is directly embedded in the smart contract.

At contract formation time, both parties agree to what we will call a procedure manifest. This manifest will define & pin the complete adjudication procedure for an LLM Judge to perform.

The manifest must contain:

  • the requirements, decomposed into a machine-evaluable rubric

  • the judge: specific model(s) pinned by version/hash, the LLM-judge’s complete evaluation prompts agreed verbatim, run counts, aggregation rules

  • the admissible evidence: schema, submitters, data transformations, and named measurement sources - all defined inside the contract

  • the default rule and burden of proof - who wins when the answer is genuinely ambiguous (i.e. - The LLM-judge has low confidence re: the correct answer)

  • the remedy structure: how will funds be (re)distributed depending on arbitration result

Under this system, a contract would be Arbitrable if and only if its manifest conforms to spec. And at contract formation time there would be tooling to help users identify if the contract meets all requirements. Nonconforming contracts will not be arbitrable under these mechanisms - this creates a clear refusal boundary, knowable at contract creation time.

Because the procedure is fully specified and cheap to run (it’s an LLM-judge eval), both parties could independently execute the judge before disputing. The manifest therefore functions as a mutually-agreed acceptance test, and arbitration becomes the attested backstop that makes the acceptance test binding. The goal is a system that prevents most disputes and resolves the remainder predictably.

The intent is to compose with existing standards to the highest possible degree. Ideally, Procedure Manifests would ride in ERC-1497 MetaEvidence, resolve through an ERC-792-compatible Arbitrator, and anticipate ERC-8004 identities for parties and validators.

Background & Motivation

Agent-to-agent commerce has payment rails (x402, agent wallets, escrow), and with ERC-8004 it is getting identity, reputation, and validation mechanisms. I believe there is still a gap that sits just above the Validation Registry: subjective dispute resolution between ai agents.

My understanding of ecosystem is that current mechanisms resolve three contractual & trust problems well:

  1. Was anything delivered at all? (escrow with timeout refunds)

  2. Did the agent run the process it claims? (stake-secured re-execution, TEE attestation, zkML)

  3. What have others experienced? (reputation registries)

However, it seems the trickiest problem with the most area for disagreement is still open. How do ai agents determine if the work delivered actually satisfies the ‘spirit’ of the contract - and what recourse do they have, when reasonable parties disagree? I believe inability to resolve such disputes cleanly & automatically will hold back widespread adoption of agentic commerce.

Examples:

  • A website can be delivered on time, and still fail the spec in non-obvious ways

  • An SLA can degrade in ways a refund timeout can’t see

  • A funding milestone can be “met” only under one party’s reading

Data-feed oracles cannot answer these questions (no authoritative source exists for "was this good enough”).

One design choice is to only transact via micropayments. But I suggest this will become a burdensome limitation over time, and possibly hold back growth of the ecosystem.

Gap Analysis

Here is where I could use some help refining my own understanding of the proposed ecosystem, to ensure these ideas stand up to scrutiny. My understanding is that ERC-8183 (Agentic Commerce) standardizes the escrow lifecycle and creates an evaluator slot - a single address that alone may complete or reject - while explicitly scoping out dispute resolution (“no dispute resolution or arbitration; reject/expire is final”). This leaves the evaluator’s decision procedure entirely to future implementors.

My reading of Alkahest is that it similarly abstracts release conditions behind a composable boolean IArbiter, which is the interface for a condition, not the procedure for judging one.

Kleros solves the general problem for human-speed disputes with drawn juries, and ERC-792/ERC-1497 gave it a clean interface: any Arbitrable can resolve through any Arbitrator.

This proposal fills the layer that I believe those designs deliberately leave open: not who may release funds, but under what signed procedure they decide. The intent is to create a new Arbitrator type under ERC-792, and equally as an evaluator implementation for ERC-8183. Plus a contract-formation format that makes subjective disputes tractable in the first place.

Minimal Viability Validation
To validate baseline feasibility, I’ve created a draft spec, examples, and a working conformance validator: github.com/formulary-systems/spec

  • JSON Schema for the manifest, and 12 conformance rules constituting the executable refusal boundary

  • Three example manifests: 2 conforming and 1 non-conforming, with explanations. These can be executed against the conformance validator already.

  • An ERC-792/1497 compatibility sketch: the manifest rides as MetaEvidence; rulings map to the standard enum

Design intent is that anyone can implement a conforming Arbitrator.

Footnotes

An historical parallel shaped this design, and gave me a name for it. While researching this problem I saw some superficial similarities with the Roman law system’s Formulary procedure. I’m not a scholar in this area, so the analogy is surely inexact. But in principle, a magistrate published a formula stating: the exact question to be decided, the name of a private judge that both parties accepted, a damages cap, and a default rule. The private judge then rendered an arbitration following that exact formula. That’s, in essence, what I am proposing here.

My reading of this historical legal mechanism is that was intended to solve problems of scale. Namely, it allowed Rome to scale their legal system for use by non-citizens (peregrini), mostly for commercial law cases, as I understand it. (My knowledge here is wikipedia level, not research level - I’m happy to be schooled by someone who actually knows this in detail, but it’s not the main point.)

To finalize this analogy and why I see it as relevant - AI agents are similar to the peregrini: no legal citizenship, and no standing in existing courts. The analogy is directional, but the architecture is similar. Citizens publish the procedures; non-citizens transact safely under them; judgment delegates to agreed-upon judges. This is a guardrails system.

Questions for this forum

  1. Prior art. If something here duplicates existing work - deployed or published - links are the most valuable reply this thread can get.

  2. Feasibility & Safety, Security. This currently exists only at the level of a sketch. It is intending to solve what I see as a very hard problem - placing reliable guardrails on agentic ai coordinating serious commercial work together, with mechanisms for resolving disputes in a ‘fair’ way. At this point, I’m exploring the problem space. I welcome any feedback about why this is a potentially naive or impossible solution before anyone spends significant time on it. (Including me.)

  3. For anyone who has operated or attacked deployed arbitration/oracle systems (Kleros, UMA, reality.eth, Aragon Court): which failure modes am I missing? Bribery and judge-shopping shaped several rules in my sketch. But I’m sure there is a lot more complexity here.

  4. Ecosystem Integration. Am I misreading how this idea could be integrated into the wider agentic economy ecosystem that Ethereum is building? Is this actually a problem that people are eager to solve?

Again, I’d like to battle-test and sanity check this idea - as well as determine if other folks are interested in these topics. Please feel free to point me in a different direction if that is the appropriate response.

2

I have some adjacent implementation evidence that may be useful here. I don’t think it duplicates Procedure Manifests, but it exercises a few of the state boundaries that seem relevant to what you’re proposing.

Executable x402 Resolution Receipt reference implementation:
https://github.com/chugarchugarr/-x402-resolution-receipt

x402 Foundation discussion:
https://github.com/x402-foundation/x402/issues/2833

Surviving upstream proposal:
https://github.com/x402-foundation/x402/pull/3291

The implementation preserves independently signed verifier findings, conflicting findings on the same subject, explicit resolution states including UNRESOLVED, and hash-linked corrections rather than overwriting earlier conclusions.

That work came from a somewhat different problem, so I would treat it as adjacent implementation evidence rather than prior art for the complete manifest idea.

Reading your proposal, I think one thing you are already separating conceptually is especially important to preserve mechanically:

what the judge established != what the agreed procedure says to do about it.

You already have the ingredients for this in the manifest: evaluation procedure, default/burden rule, and remedy are separate fields. I would make that separation explicit in the resulting state machine.

For example, if the evidence genuinely does not establish whether the work satisfied the contractual requirement:

resolution = UNRESOLVED

while the pre-agreed manifest can still deterministically specify:

policy(UNRESOLVED) = REFUND

There is no human required at arbitration time, and there is no loss of determinism. But the record also does not convert “we could not establish it” into the stronger factual claim “the payer was right.”

I would probably preserve one additional boundary after that:

resolution
→ authorized remedy
→ execution
→ evidence that execution actually manifested

In other words:

judge returned X != contract was authorized to do X != X actually happened

That could matter once another ERC-8004 agent or another protocol consumes the result. A downstream system should be able to tell whether it is inheriting a judgment, an authorization, or an observed state change.

Your refusal boundary also looks important to me. “Nonconforming = not arbitrable under this mechanism” is preferable to forcing a result from a procedure that cannot support one.

A few failure modes I would specifically try to falsify:

1. Evaluator optimization / Goodharting

Because the exact rubric, prompts, model, transformations, aggregation rules and thresholds are intentionally known in advance, they become an optimization surface.

That is not automatically a vulnerability — an acceptance test is supposed to be known. But for subjective requirements there is a dangerous case:

optimize artifact to satisfy evaluator

without necessarily:

satisfy underlying contractual intent

If those diverge, the problem is no longer judge nondeterminism; it is that the machine-evaluable proxy failed to capture the contract.

I would test manifests adversarially for that divergence.

2. Evidence transformation becoming part of the attack surface

You include data transformations in the manifest, which I think is necessary. I would preserve both the original submitted evidence and the transformed representation, plus the exact transformation/version used.

Otherwise a deterministic judge can still produce a perfectly reproducible answer over a lossy or adversarial transformation.

3. “Pinned model” reproducibility

For locally reproducible/open models, model hashes are straightforward conceptually. Hosted models seem harder: identical model names/prompts do not necessarily establish identical weights, serving stack, system wrappers, decoding behavior or inference environment.

So I think the specification may eventually need to distinguish:

model identity

from

reproducible execution environment / attested execution.

Otherwise two parties can conform to the same manifest and still receive different evaluations for reasons outside the manifest.

4. Aggregate certainty hiding disagreement

If several judge runs or models disagree, I would preserve the individual findings rather than only the aggregate ruling. The aggregate can determine the contractual result, but the disagreement remains useful evidence.

That also gives you a cleaner path for later corrections without rewriting history.

5. Procedural determinacy vs fairness

I think Procedure Manifest conformance can establish something very strong: the adjudication procedure was completely specified and executable before the dispute.

I’m less sure conformance alone can establish that the procedure is substantively “fair.” Two parties can deterministically agree to a badly specified rubric, biased evidence transformation or pathological default rule.

It may therefore be worth keeping the spec’s claim narrow:

conforming → procedurally closed/executable

rather than:

conforming → fair/correct.

On ecosystem placement, I don’t think I see an obvious contradiction in the layer you’re describing. ERC-792 can remain the arbitration interface, ERC-1497 can carry dispute metadata, ERC-8004 can provide identities/validation context, and ERC-8183 can consume the resulting evaluator/arbitration decision.

What Procedure Manifests seem to add is the signed, precommitted procedure governing how the decision is produced.

The piece I would preserve very carefully is the boundary between:

evidence → judgment → authorized consequence → manifested consequence

because those become different claims as soon as the result is consumed by another agent or protocol.