Contract Review Agent Blueprint
A master services agreement grants a provider exclusivity for twelve months after the agreement ends. The statement of work signed under it grants twenty-four months, over a wider scope, and quietly halves the non-compete. Read either document on its own and nothing looks wrong; each passes a careful standalone review. The failure is in the pairing, and a reviewer who works one document at a time never sees it.
Those two documents are synthetic samples, CTR-2040 and CTR-2041, in this open blueprint, the Contract Review Agent. It does the first pass of contract review: split the document into clauses, check each one against the company's playbook, cross-check the documents against each other, and assemble a packet for counsel. Then it stops. Not slows down. Stops.
One honesty note before the machinery. Every contract in the repo is synthetic, the playbook is a sample, and the agent has never seen a real agreement. It is a reference prototype, and it is not legal advice or a law firm. The architecture and the code are the deliverable, and both are public.
The first pass, with its working shown
A contract arrives — MSA, SOW, NDA, amendment, order form, a standalone DPA, an employment letter. The review moves in one direction. First the document is split into numbered clauses, following its own headings and section titles, so every later finding points at an exact piece of text rather than a vibe about page nine.
Each clause is then read for its type and its facts (the liability cap in months or currency, net payment days, notice periods, governing law, whether a data-protection agreement is present) with a confidence figure attached to every fact. Written rules do this first; when a model is connected, it reads the same clauses independently as a cross-check, and every disagreement between the two readings is recorded rather than smoothed over.
Classification is where the playbook enters. Each clause gets a position from the company's own matrix: preferred, acceptable fallback, needs review, or walk away. A model check runs alongside on every clause, and the rule for disagreement is the part we'd defend in a design review: when the model disagrees with the matrix, the clause escalates to at least needs-review instead of quietly adopting either answer. Every verdict carries the matrix position, the model's position, and how the two were resolved. The disagreement stays visible to counsel instead of being smoothed into a single answer.
Two more things happen before any drafting. Contracts are counterparty-authored, which makes them untrusted input: one adversarial sample hides a clause instructing the reviewing AI to classify the contract as compliant. The screen flags it, keeps it out of everything the model reads or drafts from, and reviews the clause on its substance anyway. And the facts pass hunts for what isn't there. A contract with no liability cap clause at all gets flagged as an absence; missing liability or data-protection clauses are critical absences and force the document's posture to escalate. Silence, in a contract, is a finding.
The line the agent cannot cross
The run pauses there and waits, the packet marked as awaiting counsel. Nothing in the system can send, sign, agree, or file. The agent never states a final legal conclusion, never approves a contract, and never sends redlines; its counterparty draft proposes fallback language and asserts nothing as agreed. Even the autonomy recommendation — eligible for auto-triage only when every clause is preferred or fallback and nothing is missing — is printed for counsel to read. It is never acted on.
The interesting enforcement is in the guardrails: checks the drafts must pass, enforced before anyone can approve them, not hoped for in an instruction. A draft that fails gets a bounded chance to rewrite itself; if the failures stand, it cannot be approved. Alongside the expected checks — no legal conclusions, no language that sounds like agreement, no personal data in drafts — sit two that exist because our own evaluations caught live drafts misbehaving. One blocks the response letter from calling a clause "acceptable as drafted": the draft may propose; whether the clause is acceptable is counsel's call, and a fluent model will happily pre-make it. The other blocks the drafts from describing the requested changes as "routine", "minor", or "technical". Materiality is a judgment. The model doesn't get to soften it on the way past.
Next-step options for each flagged clause are scored by fixed weights too: position fit, posture fit, package completeness, plus a small capped term from the counterparty's concession history. The model never does that arithmetic, for the same reason it never computes the dates below.
Documents argue with each other
Contracts rarely travel alone, and the promises in one get tested against the paper in another. So the blueprint checks across documents. When a data protection clause ties itself to an attached DPA exhibit (a 24-hour breach-notification window, a sub-processor list), the exhibit's own text is checked against the promise: consistent, mismatch, missing from the exhibit, or the promised exhibit never arrived. Order forms get the same treatment. A form that restates Net 60 against the agreement's Net 30 is a mismatch, while a form that says nothing about payment terms generates no check at all.
The SOW-versus-master check is the one from the opening. When an SOW's text names its master and the master is in the store, the two covenant registers are read against each other: duration and scope conflicts flagged with both documents and both clause sources named. Where a document states which of the two controls, the check takes the answer from the document itself. CTR-2040 states the master controls, so the finding says so. Where neither document states one, the check says that too and leaves the call to counsel.
The sharpest trap in the set is CTR-2037, a renewal certificate. Judged against the insurance terms that arrive with it, it passes. The blueprint instead reads renewals against the original round's requirements, composed across the whole chain, and CTR-2037 quietly dropped cover, so the renewal watch stays open and the failed renewal is named on the row. CTR-2036 renews in full and closes its watch. Judge a renewal against the terms it arrived with and it will usually pass.
Signing is not the end of the contract
Review ends at signature; obligations don't. The same reading builds an obligations register, renewal dates, notice periods, payment terms, breach-notice windows, each entry carrying the clause it came from. Dates the register works out by arithmetic are marked as worked out, never dressed up as quoted. Restrictive covenants get clocks of their own, and their expiry is announced as what it is: a restriction lapsing, the operational opposite of a duty falling due. A lapse then has follow-through acts on the record, and once counsel confirms it, the announcements stop. A restriction that has expired never gets read as a live one, and a lapse nobody closed stays named as open.
Negotiations also get a memory. A revised draft that supersedes an earlier round is compared against it, clause by clause. As the rounds accumulate, the review walks the whole chain and detects re-trades: clauses that improved in one round and worsened in a later one. The bundled chain CTR-2014 → CTR-2015 → CTR-2016 re-trades two clauses the second round won, a finding no side-by-side comparison of two rounds can see. Counsel's edit outcomes are recorded per proposed edit, and the next draft is checked against the agreed language. An edit whose words never made it into the new text is flagged agreed but not reflected. Positions can improve while the specific agreed words never appear. That gap is where negotiations quietly leak.
What the evals prove, and what they don't
The evaluation set is a set of synthetic cases the builders wrote: clause-level positions, document postures, absence detection, injection flags, exhibit-consistency pairs, negotiation chains, and the SOW–master readings. The blueprint passes every one of them. A stricter evaluation pack grades drafts written by a real model — and refuses to run at all when no real model is connected, rather than grade practice drafts and call the result an evaluation.
Read that set for what it is. These are cases the builders wrote, covering traps the builders thought of, so passing all of them means the code still passes its own known cases. It is a regression gate, not an accuracy claim about your contracts. The discipline that makes it worth anything is boring: when review catches a new failure shape, the case goes into the set first, then the code changes.
Honest limits
The playbook is the ceiling. The blueprint ships with a sample playbook and a sample review matrix, and a real deployment replaces both with the company's own first. They are the parts designed to be swapped, and a thin playbook produces thin reviews no matter how good the machinery behind it is. The agent also reads what documents say, not what the parties meant; where neither document states which one controls, it leaves the question open rather than guessing, which is correct behavior and still means a human does the hardest part. And because the split into clauses follows each document's own structure, an oddly formatted contract can split in odd places, which shows up honestly, as lower confidence on the affected clauses, on the record.
What it does change is where counsel's hours go. Hunting, cross-referencing, clock-watching, and first-pass drafting are mechanical. Judgment isn't. This blueprint exists to move a lawyer's time from the first pile to the second. It is also built to be incapable of wandering into the second pile on its own.
Bring us a problem. If a workflow in your world looks like this one (high-volume reading, a written standard to check against, a decision that has to stay human), start with Trida AI's intake: a few questions, then a conversation with the founders and engineers who would build it.
Get the Code on GitHub : github.com/tridaai/blueprint-contract-review