Agreement Graph · a research project
A portfolio of agreements is a typed, auditable graph. Every state change guarded. Every transition recorded. Every dependency visible before you sign, renew, or terminate.
01
A master services agreement. Active, governing, binding. Most contract software stops here: a PDF in a folder.
02
Two statements of work hang off it. Their terms, their renewal dates, their fate: inherited from the parent.
03
A data-processing addendum rewrites the parent. From this moment, the original text alone is no longer the truth.
04
Signatories, counterparties, reviewers. Identity and authority sit on every transition, not in a spreadsheet next to it.
05
What breaks? Two SOWs and an addendum, surfaced instantly. The question that takes legal ops three days is answered in one query.
06
Typed edges. Guarded transitions. An append-only audit trail. Keep scrolling for the design, or jump straight to the playground.
The argument
A contract is not a flat file. It is a web of parties, obligations, and dependencies, and underneath it, a single enforceable event: the moment identity, intent, and authorization line up and a state changes.
Most contract software treats agreements as documents to store and search. That misses the point. The valuable thing isn't the text, it's the transition: who is bound, under what authority, from what state to what state, and whether you can prove it later.
The Agreement Graph models that directly. Every agreement is a node with a lifecycle. Every change of state is a guarded, audited transition. Every relationship between agreements, a master agreement to its SOW, an amendment to its original, a renewal that supersedes the old terms, is a typed edge in a graph the operator owns.
Agreements represent enforceable state transitions:
identity → intent → authorization → auditability → state change.
Who feels this
01
Managing 500+ active agreements where one MSA parents dozens of SOWs. A single renewal negotiation requires tracing every child, amendment, and addendum by hand. That takes days and still misses things.
The question they ask every quarter: what is this contract actually governing right now?
02
Asked "can we terminate this?" and spending three days manually tracing what depends on it before they can answer. The dependency chain exists in the contracts. Nobody has ever modeled it in a way you can query.
The question that stops them cold: what breaks if we do this?
03
Inheriting an acquired company's contract portfolio with no map of the relationships. Which agreements are active? Which are expiring? Which ones are children of something already superseded? The graph answers all of it in one pass.
The question that delays every close: what obligations are we actually inheriting?
Design principles
Each one is non-negotiable. Together they define what separates a contract repository from a contract system of record.
Every transition carries a guard: a pure rule that must pass before the state moves.
submit requires at least one party and non-empty content. accept_for_review
requires a party with the reviewer role. Guards are deterministic and free of side effects.
Every successful transition emits an audit event recording the actor, source state, destination state, timestamp, and context. Events are never modified or deleted. The trail is the record of authority.
Agreements link to each other through typed edges: parent_of,
supersedes, amends, depends_on. The graph is
the queryable asset: what depends on what, what is expiring, what was replaced.
Lifecycle
Nine states. Eleven transitions. Each transition is a pure function:
apply_transition(agreement, name, actor, context) returns a new agreement and
an audit event, or raises. Storage is only written after both succeed.
apply_transition( )
agreement.state = "draft" transition = "submit" actor = "acme-corp"
returns
agreement.state = "proposed"
audit_event = {
from: "draft", to: "proposed",
actor: "acme-corp", at: "…"
}
Graph model
A master agreement parents its statements of work. A renewal supersedes the old terms. Parties connect through roles. Hover a node to inspect its relationships; click to isolate the connected subgraph.
Ingestion pipeline
A three-layer pipeline modeled on the Semantic Medallion pattern. Each layer is defined by what it delivers semantically, not by how it is stored. Bronze lands raw documents. Silver structures and identifies entities. Gold publishes the unified graph as RDF.
Constraints
Operator owns all data in plain, portable form. Git-friendly, no SaaS lock-in. The lesson from closed memory systems: if you can't export it, you don't own it.
Every extracted contract fact cites the exact span it came from. Low-confidence extractions get flagged, never silently filled. The system never asserts what it can't point back to.
W3C DCAT for catalog metadata, PROV-O for lineage, RDF + SPARQL at the Gold layer. Interoperable out of the box instead of a bespoke schema nobody else speaks.
The UNDER_REVIEW state is a built-in human gate. Nothing reaches
APPROVED without an identified reviewer acting on it. AI augments the review;
it doesn't replace the signature.
Interactive demo
One Master Service Agreement. Two Statements of Work that depend on it. A mutual NDA expiring in 18 days. A draft employment agreement under legal review. Click any contract to see what is at risk. Try to terminate the MSA and watch what breaks.
This demo runs on 5 contracts. At 1,000, manual tracking is roughly 3 full-time procurement roles. At 10,000+, manual tracking is impossible. The graph is the only way.
Hover to trace relationships · click a node to open it · drag to rearrange
Select a contract above, then run a query.
Agreement Graph is a research project exploring contracts as enforceable state machines. If the model resonates, breaks, or sparks an idea, I'd genuinely like to hear it. Feedback, critiques, and contributions all shape where this goes next. The repository will be made public soon.
One free portfolio session. Your contracts are parsed locally in your browser and never uploaded.
Drop .txt contracts (one per file), or paste text below. Separate multiple pasted contracts with a line of ---.
Client-side parsing extracts parties, dates, amounts, and relationships. For clause-level extraction with source-span citations, .
Your first portfolio is on the house. To analyze another portfolio, or to unlock LLM-grade clause extraction with source-span citations, let's talk.