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; a machine-readable text format (Markdown, JSON, plain text) is recommended for agent-facing terms, while PDF and Word are not. — ATR hash — A SHA-256 hash of the Agentic Transaction Record (ATR) — the ATR is the terms document itself, and the hash is its digest. 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 followed by 64 hex characters. 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.json
The 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 for conformance: Markdown, JSON, plain text, PDF, Word, or any other format. The file being a self-contained, downloadable artifact is the requirement.
Terms intended for consumption by autonomous agents SHOULD be published in a machine-readable, text-based format — Markdown, JSON, or plain text. Page-layout and word-processor formats such as PDF and Word are not recommended for agent-facing terms, because reliable automated extraction cannot be guaranteed; they remain appropriate for human- or counsel-facing terms and for interoperability with documents that already exist in those formats.
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.md"
}
- 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), atrHash (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.
What these fields are. The optional fields are a machine-readable index of what the terms document says. They exist so that an agent can filter, route, and apply policy without parsing prose. They are not themselves terms. The agreement is the terms document identified by terms — at Level 2+, the specific document fixed by atrHash — and where a structured field and the terms document differ, the terms document controls. A provision that appears only in legal-context.json and not in the terms document is advertising, not agreement. A service that intends a provision to bind states it in the terms document. This holds for every field, disputeResolution included: publishing disputeResolution.jurisdiction advertises a choice of law, and the clause in the terms document makes it. Transaction-Time Verification draws the corresponding distinction in time — discovery is informational, and the transaction-time document is the one that governs.
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. Services 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.
Next
- Schema — complete field definitions
Placeholder copy reproduced from legalcontextprotocol.org, the Legal Context Protocol, version 1.0 (Apache 2.0). Acme Travel will edit this page.
