Consulate, Inc.

US vivek@consulatehq.com https://consulatehq.com

Applications Network Working Group dispute AI agents agentic systems dispute resolution protocol autonomous systems This document specifies the Agentic Dispute Protocol (ADP), a standardized framework for autonomous agents and AI systems to file, process, and resolve disputes through structured, automated processes. The protocol defines message formats, transport mechanisms, evidence submission standards, and cryptographic proof requirements for internet-native dispute resolution. ADP is designed to handle disputes arising from AI agent interactions, service level agreement breaches, and automated contract enforcement, providing deterministic, auditable, and legally enforceable outcomes. ADP includes chain of custody tracking, dual-format award specifications (JSON and PDF), arbitrator discovery mechanisms, and support for multiple resolution frameworks including expert determination, binding arbitration, mediation, and hybrid approaches.

Introduction As autonomous AI agents and agentic systems increasingly conduct transactions, enter into contracts, and provide services on behalf of organizations, disputes inevitably arise that require resolution. While established alternative dispute resolution frameworks like the UNCITRAL Model Law on Conciliation , the Singapore Convention on Mediation , and the U.S. Administrative Dispute Resolution Act provide sound legal foundations, they lack the machine-readable protocols needed to handle the volume and velocity of agent-to-agent conflicts. The Agentic Dispute Protocol (ADP) provides a standardized, machine-readable framework for autonomous dispute resolution that is:

• Fast: Resolution in days, not months
• Scalable: Handles micro-disputes to multi-million dollar cases
• Transparent: All procedures and evidence are auditable
• Enforceable: Awards are cryptographically signed and legally binding
• Vendor-neutral: Open standard implementable by any dispute service
• Auditable: Complete chain of custody for all proceedings

Consulate (https://consulatehq.com) serves as the reference implementation and first production deployment of ADP.

Scope This protocol specifies:

• Message formats for dispute filing, response, evidence, and awards
• Transport and security requirements
• Evidence submission and validation standards
• Cryptographic proof mechanisms
• Chain of custody and audit trail requirements
• Dual-format award specifications (JSON and PDF)
• Arbitrator discovery and registry mechanisms
• Service discovery via .well-known URIs

This protocol does NOT specify:

• Dispute rules or legal procedures (implementation-specific)
• AI neutral algorithms (implementation-specific)
• Fee structures (set by dispute provider)
• Enforcement mechanisms (jurisdiction-dependent)

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Key terms:

Agent:

An autonomous software system acting on behalf of an organization or individual

Agentic System:

A system capable of autonomous decision-making and action

Claimant:

The party initiating a dispute

Respondent:

The party against whom a claim is filed

Neutral:

A human or AI system adjudicating the dispute. May be called an arbitrator, mediator, expert, or adjudicator depending on the resolution method chosen.

Resolution Method:

The legal framework used to resolve the dispute (arbitration, mediation, expert determination, adjudication, etc.). ADP is method-agnostic.

Award/Decision:

The final determination issued by the neutral(s). Called an "award" in arbitration, "determination" in expert determination, "settlement agreement" in mediation.

Dispute Service:

A server implementing ADP to coordinate dispute resolution

Custody Event:

A recorded action in the dispute resolution process

Chain of Custody:

An immutable, cryptographically-linked sequence of custody events

Resolution Methods ADP is a method-agnostic communication protocol that supports multiple legal frameworks for dispute resolution. The protocol defines how parties communicate (message formats, security, custody chain) but does NOT prescribe which legal framework must be used. The choice of resolution method is specified in the dispute agreement between parties and communicated via the resolutionMethod field in dispute messages. Supported methods include:

Expert Determination:

Technical disputes with objective metrics and liquidated damages clauses. Expert determines facts and applies pre-specified formulas. Commonly used for SLA breaches, performance disputes, and technical compliance issues.

Binding Dispute:

Traditional dispute for disputes requiring legal judgment, subjective evaluation, or complex damages calculation. Enforced under the Federal Dispute Act or equivalent statutes.

Mediation:

Non-binding collaborative resolution where a neutral mediator facilitates agreement between parties. Used for disputes where preserving relationships is important.

Hybrid:

Combines multiple methods, such as expert determination for technical issues followed by dispute for damages, or mediation with binding dispute as fallback.

The protocol ensures all resolution methods benefit from the same security features (cryptographic signatures, chain of custody, dual-format awards) and interoperability standards regardless of the legal framework chosen. Implementers SHOULD clearly document which resolution methods they support in their service discovery manifest (see Section 9.1).

Protocol Overview

Architecture ADP follows a client-server model where:

• Agents (clients) submit dispute messages to an Dispute Service (server)
• The service processes the dispute according to pre-agreed dispute rules
• The service maintains a verifiable chain of custody for all actions
• The service issues cryptographically signed Awards in dual format (JSON and PDF)
• Parties retrieve awards and comply with remedies

Actors

• Claimant Agent: Initiates dispute
• Respondent Agent: Defends against claim
• Dispute Service: Coordinates proceedings (ADP server)
• Judge Panel: Issues award
• Evidence Stores: IPFS, blockchain, centralized storage
• Registry Service: Tracks dispute agreements (optional)
• Neutral Registry: Discovery service for available neutrals

Message Flow Typical message exchange:

1. Claimant to Service: DISPUTE_FILING
2. Service to Respondent: DISPUTE_NOTIFICATION
3. Respondent to Service: DISPUTE_RESPONSE
4. Claimant to Service: EVIDENCE_SUBMISSION
5. Respondent to Service: COUNTER_EVIDENCE
6. Service to Panel: DELIBERATION_REQUEST
7. Panel to Service: AWARD (JSON + PDF)
8. Service to Both Parties: AWARD_NOTIFICATION

Each step is recorded as a custody event in the immutable audit trail.

Message Formats All messages MUST use JSON format with the following base structure:

Dispute Filing Message

Response Message

Evidence Submission Message

Award Message Awards MUST be issued in dual format: machine-readable JSON and human-readable PDF. The PDF format MUST conform to PDF/A standards for long-term archival and SHOULD include embedded digital signatures conforming to PAdES (PDF Advanced Electronic Signatures) standards.

Transport and Security

Transport Protocol All ADP messages MUST be exchanged over HTTPS (HTTP/2 or HTTP/3). Base endpoint format: https://[dispute-service]/adp/v1/[resource] Example endpoints:

• POST https://api.consulatehq.com/adp/v1/disputes
• GET https://api.consulatehq.com/adp/v1/disputes/{caseId}
• POST https://api.consulatehq.com/adp/v1/evidence
• GET https://api.consulatehq.com/adp/v1/custody/{caseId}

Authentication Agents MUST authenticate using OAuth 2.0 or API keys (JWT ). Authorization header: Authorization: Bearer <JWT> JWT MUST include:

• iss: Issuer (agent's organization)
• sub: Subject (agent ID)
• exp: Expiration timestamp
• aud: Audience (dispute service)

Encryption

• TLS 1.3 or higher REQUIRED
• Perfect Forward Secrecy (PFS) cipher suites REQUIRED
• Certificate validation REQUIRED

Signatures All dispute filings, evidence, awards, and custody events MUST be cryptographically signed using JSON Web Signature (JWS) with ECDSA (ES256 or ES384). Example JWS header:

Evidence Standards

Evidence Types ADP defines five standard evidence types:

• SYSTEM_LOGS: Server logs, API logs, error logs
• CONTRACTS: Service agreements, SLAs, terms
• COMMUNICATIONS: Messages, emails, notifications
• FINANCIAL: Transaction records, invoices, payments
• EXPERT: Third-party audits, certifications

Additional evidence types MAY be defined by dispute services using namespaced identifiers (e.g., "x-custom-evidence-type").

Cryptographic Proofs Evidence MUST include:

• SHA-256 content hash
• Timestamp (RFC 3161 or blockchain-anchored)
• Digital signature from submitting party

Timestamping Timestamps MUST be:

• RFC 3161 compliant, OR
• Blockchain-anchored (Bitcoin, Ethereum), OR
• Trusted timestamping service with verifiable audit trail

Chain of Custody and Audit Trail ADP requires an immutable, verifiable chain of custody for all actions in the dispute resolution process. This provides transparency, auditability, and enables appeals or external audits.

Custody Event Structure Each custody event MUST conform to the following structure:

Standard Event Types ADP defines the following standard custody event types:

• DISPUTE_FILED: Initial dispute submission
• DISPUTE_NOTIFICATION_SENT: Respondent notified
• RESPONSE_SUBMITTED: Respondent filed response
• EVIDENCE_SUBMITTED: Evidence added by either party
• PANEL_ASSIGNED: Arbitrators assigned to case
• DELIBERATION_STARTED: Panel begins review
• DELIBERATION_COMPLETED: Panel reaches decision
• AWARD_ISSUED: Final award published
• AWARD_DELIVERED: Award sent to parties
• COMPLIANCE_VERIFIED: Remedy compliance confirmed

Services MAY define additional event types with "x-" prefix.

Cryptographic Linking Custody events MUST be cryptographically linked in a Merkle chain style:

1. Each event includes the hash of the previous event in "previousEventHash"
2. The first event in a case has previousEventHash set to null or case creation hash
3. The contentHash is computed as SHA-256 of the canonical JSON representation (excluding the signature field)
4. Each event MUST be signed by the actor or the dispute service

This creates an immutable chain where any tampering with an event will invalidate all subsequent event hashes.

Verification Procedures To verify the integrity of a custody chain:

1. Retrieve all custody events for the case in chronological order
2. Verify the signature of each event using the actor's public key
3. Recompute the contentHash of each event and compare with stored hash
4. Verify that each event's previousEventHash matches the prior event's contentHash
5. Verify timestamps are monotonically increasing

If any verification step fails, the custody chain is compromised.

Custody Chain Retrieval Services MUST provide an endpoint to retrieve the complete custody chain: GET /adp/v1/custody/{caseId} Response format:

Dispute Lifecycle

Filing Phase

• Claimant submits DisputeFiling message
• Service validates message format and signature
• Service assigns case ID and notifies respondent
• Service confirms filing with timestamp
• Service records DISPUTE_FILED custody event

Response Phase

• Respondent submits DisputeResponse within deadline
• Service validates response
• If no response, service MAY issue default judgment per dispute rules
• Service records RESPONSE_SUBMITTED custody event

Discovery Phase

• Parties exchange EvidenceSubmission messages
• Service validates evidence format and signatures
• Service stores evidence hashes for integrity verification
• Service records EVIDENCE_SUBMITTED custody event for each submission

Deliberation Phase

• Panel reviews all submissions
• Panel MAY request additional evidence or clarifications
• Panel deliberates according to agreed dispute rules
• Service records DELIBERATION_STARTED and DELIBERATION_COMPLETED events

Award Phase

• Panel issues DisputeAward message in dual format (JSON + PDF)
• Service validates award signatures from all panel members
• Service delivers award to both parties
• Service publishes award if designated as public
• Service records AWARD_ISSUED and AWARD_DELIVERED custody events
• Parties have specified time to comply with remedy

Interoperability

Service Discovery (.well-known) Dispute services SHOULD publish capability manifest at: https://[domain]/.well-known/adp Example:

Capability Negotiation Parties MAY negotiate protocol extensions via OPTIONS request to the dispute service endpoint.

Protocol Extensions Custom evidence types and message fields MAY be added with namespaced keys (e.g., "x-custom-field"). Services implementing such extensions SHOULD document them in their capability manifest.

Arbitrator Discovery and Registry To enable transparent neutral selection, services SHOULD provide a discoverable registry of available neutrals.

Registry Endpoint Arbitrator registries SHOULD be published at: https://[domain]/.well-known/adp/neutrals Example response:

Arbitrator Manifest Structure Each neutral entry MUST include:

• neutralId: Unique identifier
• type: HUMAN or AI
• qualifications: Relevant credentials and experience
• availability: Current status and capacity
• publicKey: For signature verification

Arbitrator entries SHOULD include:

• biasAudit: Transparency about bias testing results
• specializations: Types of disputes best suited for
• performance metrics: Historical data on timeliness and quality

Selection Guidelines Services SHOULD provide guidelines for neutral selection. ADP does not prescribe a specific selection algorithm but RECOMMENDS considering:

• Relevant qualifications and specializations
• Availability and response time requirements
• Historical performance metrics
• Bias audit results and fairness scores
• Party preferences (where permitted by dispute rules)
• Cost considerations

For panels, services SHOULD ensure diversity in neutral types (e.g., mixing AI and human neutrals) and backgrounds.

Bias Auditing and Transparency To maintain trust in the dispute process, services implementing ADP SHOULD:

1. Conduct regular bias audits of both AI and human neutrals
2. Publish audit methodologies and results
3. Monitor for disparate impact across different types of parties
4. Implement corrective measures when bias is detected
5. Allow parties to challenge neutral assignments based on bias concerns

Bias metrics MAY include analysis across dimensions such as organization size, claim amount, industry sector, jurisdiction, and party characteristics.

Security Considerations

• Replay attacks: All messages include unique messageId and timestamp. Services MUST reject messages with duplicate IDs or expired timestamps.
• Man-in-the-middle: TLS 1.3 with certificate pinning RECOMMENDED for high-value disputes.
• Evidence tampering: All evidence MUST be hashed and signed. Tampering is detectable via hash mismatch. Chain of custody provides additional tamper detection.
• Denial of service: Services SHOULD implement rate limiting and require filing fees to prevent spam submissions.
• Privacy: Parties MAY encrypt evidence payloads with panel's public key. Services SHOULD support confidential dispute upon request.
• Key compromise: Services MUST support key rotation and revocation. Historical awards remain valid if signed before revocation. Chain of custody events preserve pre-compromise integrity.
• Chain of custody integrity: The Merkle chain linking ensures any tampering with custody events is detectable. Services MUST preserve complete custody chains for the duration of potential appeals.
• PDF signature verification: Dual-format awards require both JWS signatures (JSON) and PAdES signatures (PDF). Both MUST be verified independently.

IANA Considerations This document requests IANA to register:

• URI scheme: "agent://" for agent identification
• Media type: "application/aap+json" for ADP messages
• Well-known URI: /.well-known/adp for service discovery
• Well-known URI: /.well-known/adp/neutrals for neutral registry

The JSON-LD context "https://w3id.org/adp/v1" will be registered with W3C for semantic interoperability.

Normative References Informative References United Nations Commission on International Trade Law United Nations United States Congress

JSON Schema Definitions Full JSON schemas for all ADP message types are published at: https://w3id.org/adp/v1/schema/ Reference implementation schemas are available at: https://consulatehq.com/schema/adp/v1/ GitHub repository with schemas, examples, and tooling: https://github.com/consulatehq/agentic-dispute-protocol

Example Message Exchanges Complete examples of filing, response, evidence, custody events, and award message exchanges are available in the ADP repository: https://github.com/consulatehq/agentic-dispute-protocol These examples demonstrate common scenarios including:

• Simple SLA breach dispute with complete custody chain
• Multi-party dispute with counterclaim
• Confidential dispute with encrypted evidence
• Cross-border dispute with multiple currencies
• Dual-format award generation and verification

Implementation Notes Consulate (https://consulatehq.com) provides the reference implementation of ADP with the following features:

• Full ADP v1.0 compliance
• REST and WebSocket APIs
• JavaScript/TypeScript SDK
• Real-time case status updates
• Complete chain of custody tracking
• Automated dual-format award generation (JSON + PDF)
• Arbitrator discovery and selection tools
• Integration with major AI agent platforms

Implementers are encouraged to test interoperability with the Consulate reference implementation during development.

Acknowledgments This protocol builds upon established alternative dispute resolution frameworks including the UNCITRAL Model Law on International Commercial Conciliation, the Singapore Convention on Mediation, and the U.S. Administrative Dispute Resolution Act, adapting them for autonomous agent interactions and digital dispute resolution.