The Standard
The normative core: /.well-known/legal-context.json — one file, one required field.
This is the normative core of the Legal Context Protocol. A service implementing this standard publishes a JSON document at a well-known URI. The document points to the service's legal terms. The standard requires no specific technology.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals, as shown here.
Terminology
| Term | Definition |
|---|---|
| Discovery document | The JSON file served at /.well-known/legal-context.json. Contains references to the service's legal terms and optional metadata. |
| Terms document | The standalone, downloadable legal terms file referenced by the terms field in the discovery document. May be any format: PDF, JSON, Markdown, plain text, or other. |
| Content hash | A SHA-256 hash of the terms document, 0x-prefixed hexadecimal (66 characters). Identifies the exact document and proves it has not been altered. |
| Legal context | The combination of terms, jurisdiction, dispute resolution process, and temporal obligations governing a transaction. |
| Clause identifier | A content-addressed identifier for a dispute resolution clause, in the format sha256:0x<hex>. Enables verification that a clause matches a known published standard. |
Well-Known URI
A service implementing this standard MUST serve a JSON document at:
https://{domain}/.well-known/legal-context.jsonThe document MUST be served over HTTPS. The TLS certificate provides domain identity anchoring.
File Format
The discovery document MUST be valid JSON (application/json).
Legal Terms Are a Document
The legal terms referenced in legal-context.json MUST be a standalone file — a discrete, downloadable artifact. Not a section of a webpage. Not dynamically rendered HTML.
The file format does not matter: PDF, Word, Markdown, JSON, plain text, or any other format. The file being a self-contained, downloadable artifact is the requirement.
The file MUST be served via standard HTTP(S) GET. The server SHOULD include a Content-Type header declaring the file format.
Required Fields
{
"terms": "https://example.com/terms/v3.pdf"
}| Field | Type | Required | Description |
|---|---|---|---|
terms | string | REQUIRED | Absolute HTTPS URL of the legal terms document. MUST return a standalone, downloadable file. For services with only confidential/private terms, this URL MAY return a document stating that terms are provided at transaction time (see Private and Custom Terms). |
One field. That is the entire normative requirement.
Optional Fields
The discovery document supports additional fields for increasing levels of trust: termsFormat (signals machine-readable terms), contentHash (Level 2), acceptanceRequired (Level 3), disputeResolution with clauseId, source, and catalog sub-fields, returns, contact, and api (Level 4). See Schema for the complete field definitions.
Serving Requirements
The discovery document MUST be served over HTTPS.
Clients SHOULD cache the discovery document for a period not exceeding 24 hours. Clients MUST re-fetch after cache expiry. Vendors MAY include standard HTTP cache headers (Cache-Control, ETag, Last-Modified).
Extensibility
The field set is extensible. Implementations SHOULD ignore fields they do not recognize. See Schema for the complete set of optional fields.
Examples
See Examples for minimal, intermediate, and full configurations.
What the Standard Does Not Require
- No hash required
- No blockchain required
- No API required
- No cryptography required
- No third-party service required
- No on-chain primitives
- No specific technology of any kind
Any company can adopt this standard in five minutes: create a JSON file, put it on your web server. Agents learn one convention for finding terms on any service. It works for a solo developer and for JPMorgan. Everything else builds on top voluntarily.