Contract intelligence: the model reads, your playbook decides what's risky
Every company past a certain size is a party to more contracts than anyone has read. Vendor agreements, customer terms, partnerships, leases, SLAs — thousands of documents, each with a handful of clauses that matter and forty pages that don't. The people who could tell you which is which are the most expensive and the busiest in the building, so the reading happens late, unevenly, or not at all. The cost shows up as an auto-renewal nobody noticed, a liability cap that wasn't there, payment terms that quietly stretched the cash cycle.
Language models are good at reading contracts. That is the easy part, and it is worth being precise about what the hard part is.
What the system does
A contract intelligence pipeline takes a document in any format and produces a structured, checkable review:
- Extraction. The parties, dates, term and renewal, governing law, payment terms, amounts. Structured fields, so a spreadsheet of a thousand contracts becomes possible for the first time.
- Clause classification. Each provision tagged by what it is — indemnification, limitation of liability, confidentiality, termination, non-compete, data protection — so a reviewer can jump to the six that matter instead of reading forty pages.
- Risk against a playbook. The system compares each clause with your positions: the liability cap you accept, the notice period you require, the terms you never sign. Deviations are flagged with the clause quoted, the position it violates, and a plain-language note on why it matters. Not "risky" — how it departs from what you'd have written.
- Rule checks a lawyer doesn't run. Some risk is financial, not legal. Net terms longer than thirty days, an auto-renewal with a ninety-day notice window, a price escalator with no cap. Deterministic rules, applied to every contract, catch what a legal review isn't looking for.
- Summary and hand-off. A one-page brief per contract; the flagged items routed to the person who owns that kind of decision; everything cited back to the page.
Where the project is actually won
The playbook. A model can tell you a clause is an indemnification; it cannot tell you whether your company accepts uncapped indemnities from vendors of that size. That knowledge lives in a handful of people's heads, in redlines from past negotiations, and in the clause library legal already maintains. Writing it down as positions — accept, negotiate, never — is the real work of the project, and it is the part that makes the output trustworthy. Skip it and you have a highlighter.
The second thing is explanation. A flag without a reason gets ignored the second time it's wrong. A flag with the clause, the position, and the difference gets read, and gets corrected when the position was wrong — which is how the playbook improves.
What it should not do
It should not give legal advice, and it should not decide. It sorts, extracts, compares, and explains; a person with the authority to accept a risk accepts it. Frame it as triage for the people who already do the review, not as a replacement, and adoption follows.
What we learned prototyping it
We built this as a proof of concept, not for a client. The pipeline parsed contracts into clauses, used an encoder model (modernBERT) for classification and comprehension, embeddings (EmbeddingGemma) to match clauses against a small library of reference positions, deterministic checks for the financial rules — payment terms over thirty days flagged as a cash-flow risk — and a small model (Flan-T5) for the per-contract summaries. Everything on PyTorch, everything runnable inside a company's own environment.
Three things stood out. Classification was solid once we had a taxonomy that matched how a legal team actually talks about clauses, and useless before that — the taxonomy is a decision, not a default. The rule-based financial checks were the most immediately valuable output, because they found a class of risk nobody in legal review was looking for. And a risk score without the quoted clause and the position it violated was ignored in review; the citation was the product.
What production adds: the playbook written down and owned, integration with the contract management system so reviews attach to the record, and an evaluation set of already-reviewed contracts to measure the system against before anyone relies on it.