Level 4: Integrated
Hooks to legal infrastructure — dispute resolution, escrow, compliance, private terms.
This section is advisory.
Overview
For complex transactions, the legal-context.json file includes hooks to richer legal infrastructure. The standard does not prescribe an enforcement model; deployments select among several, often in combination:
- Dispute resolution systems — structured processes, institutional arbitration, mediation, online dispute resolution
- Pre-settlement verification and observational middleware — a trusted middleware observes promise against delivery, before or around settlement; suitable for high-volume, low-value flows where post-failure dispute resolution is uneconomic
- Escrow and conditional payment release — programmatic conditions on payment release; appropriate for high-value commitments where holding funds against performance is justified
- Reputation and reconciliation systems — batched reconciliation, reputation feedback, allow/deny lists; appropriate where the relationship is sustained and recourse is operational rather than legal
- Multi-party agreement management — buyer, seller, agents, principals
- Identity verification — party attestation and authorization chains
- Compliance gating — regulatory enforcement
- Returns and claims processes — operational automation
- Access-controlled private terms — gated access for confidential agreements
The right choice among dispute resolution, pre-settlement verification, escrow, reputation, and reconciliation depends on transaction value, counterparty trust, and the cost structure of recourse — not on the standard.
How It Works
{
"terms": "https://example.com/terms/v3.json",
"termsFormat": "json",
"atrHash": "0x7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069",
"acceptanceRequired": true,
"disputeResolution": {
"method": "Dispute Resolution Service Rules",
"jurisdiction": "New York, USA",
"contact": "disputes@example.com",
"clauseId": "sha256:0x<hash>",
"source": "https://www.{dispute_resolution_service}.org/clauses/commercial-arbitration",
"catalog": "https://www.{dispute_resolution_service}.org/.well-known/dispute-services.json"
},
"returns": "https://example.com/api/returns",
"contact": {
"legal": "legal@example.com",
"technical": "api-support@example.com"
},
"api": "https://api.example.com/v1/records/0xabcdef1234567890"
}The disputeResolution Object
The disputeResolution field provides structured information about how disputes are resolved:
| Field | Description |
|---|---|
method | The dispute resolution method — e.g., "Dispute Resolution Service Rules" |
jurisdiction | The governing jurisdiction — e.g., "New York, USA", "London, UK" |
contact | Contact for filing a dispute |
clauseId | Content-addressed identifier of the dispute resolution clause (sha256:0x<hex>). When present, the clause is verifiable — any party can retrieve the text and confirm it matches the hash. |
source | URL where the dispute resolution clause text can be retrieved. Any resolvable URI. |
catalog | URL of the dispute resolution provider's service catalog. When present, agents can browse offerings, parameters, and constraints, and generate customized clause specifications programmatically. |
The method, jurisdiction, and contact fields are human-readable summaries. The clauseId and source fields make the dispute resolution clause verifiable — an agent can retrieve the text, hash it, and confirm it matches the published identifier. The catalog field enables agents to browse the provider's full service menu and generate custom specifications programmatically.
The api Field
The api field is the bridge from the open standard to any legal infrastructure implementation. It provides the entry point to richer functionality:
- Record management — creating and querying agreement records
- Verification — checking document integrity and party attestations
- Dispute filing — initiating disputes programmatically
- Returns and claims — processing returns through a structured API
- Status queries — checking the state of an agreement or dispute
The api field is not specific to any single implementation. Any legal infrastructure reachable via an API endpoint qualifies. The standard provides the hook; the implementation provides the capability.
Private Terms
At Level 4, the terms may not be publicly readable. Access may be gated — only authenticated parties can retrieve private terms. This supports:
- Confidential agreements and NDAs
- Custom per-customer pricing
- Settlement agreements
- Regulated terms requiring access control
For services with only private terms, the public terms URL in legal-context.json MAY return a document stating that terms are provided at transaction time. The actual terms are delivered through the ephemeral link pattern (see Transaction-Time Verification) or the api endpoint.
When Level 4 Is Appropriate
Level 4 is appropriate for complex, high-value agreements:
- Cross-border B2B procurement
- Regulated financial instruments
- Multi-party supply chain agreements
- Transactions requiring institutional dispute resolution
- Agreements with escrow or conditional payment terms
- Any transaction where the legal infrastructure must be as robust as the commercial infrastructure