Capabilities
Ricardian Contracting
The computer science concept that makes Paper possible.
First described by Ian Grigg in 1996. First deployed at scale for AI agent work by exact.works in 2024.
Origin
A new class of document.
In 1996, cryptographer Ian Grigg described a new class of document for financial instruments: one that is simultaneously human-readable, machine-readable, and cryptographically identified. He called it a Ricardian contract, after David Ricardo's theory of value.
The concept was elegant but ahead of its time. Early implementations were theoretical or limited to simple bond certificates. The challenge was binding — how do you ensure the legal prose and the executable code describe the same agreement?
Grigg's answer: a compiler.
The binding problem
The document says one thing.
The code does another.
Every system that combines legal documents with code faces the same problem: the document says one thing, the code does another.
This is not a hypothetical. It is the default state of every "smart contract" system ever deployed. Lawyers write the prose. Engineers write the code. Nobody formally verifies they agree.
The Ricardian solution is to treat the binding as a compilation step. The legal text and the machine-readable manifest are inputs. The compiled contract — with its cryptographic identity — is the output. If the inputs conflict, compilation fails. No contract is formed.
Four properties
Human-readable
Legal prose in natural language. Enforceable in any jurisdiction that recognizes written contracts. Can be read by a judge, a lawyer, or a party to the agreement without technical knowledge.
Machine-readable
Structured data that software can parse, validate, and execute. Not a description of what to do — instructions a machine can follow without human interpretation.
Cryptographically identified
A unique identifier derived from the document’s content. Any modification to the document changes the identifier. The identifier is verifiable by anyone with the document.
Compiled
This is what distinguishes a Ricardian contract from a PDF stapled to a JSON file. The compiler validates that the human-readable and machine-readable components describe the same agreement. Inconsistencies fail compilation. Consistency produces a bound, identified contract.
Implementation
Implementation at scale.
exact.works implements the Ricardian contract pattern through Paper.
The SAISA provides the standard form — the legal prose that defines the terms of every AI agent engagement.
The Execution Manifest provides the machine-readable component — structured JSON specifying runtime, tools, acceptance criteria, settlement terms, and budget ceiling.
validateMSA() is the compiler — it checks every claim in the legal prose against every parameter in the manifest. Scope defined in Article 3 must match the tool authorization list. Success criteria in Schedule 1 must match the acceptance criteria array. Budget ceiling must match the max_budget field.
The output is a Paper: a compiled Ricardian contract with a three-component hash chain binding it to the SAISA standard form.
Why it matters
AI agents need binding agreements.
AI agents execute instructions autonomously. When something goes wrong, the question is always: what did the agent agree to do?
With a traditional contract: the prose may be ambiguous. With a smart contract: the code may not match the intent. With a Paper: the prose and the code are the same agreement, compiled and verified at formation.
The hash chain is the proof. The Trace is the record. Parler is the resolution. The Ricardian contract is the foundation.