Contract review is a citation problem, not a summarisation problem
A lawyer does not want a summary of the indemnity clause. They want to be taken to it, with the words intact, so they can form their own view. That distinction changes the whole build.
The obvious contract-review product summarises an agreement and lists the risks. It demonstrates well and it is not what a professional reviewer wants, for a reason that is easy to miss if you are not one.
A summary asks the reader to accept an interpretation they cannot check without redoing the work. If the stake is professional liability, an unverifiable interpretation is worth close to nothing. The valuable output is not the conclusion — it is being taken to the right paragraph quickly, with the original language preserved.
Retrieval, not generation
This reframes the system. The primary job is: for this question, find every place in this document that bears on it, and quote it exactly.
Which is a retrieval and citation problem with generation as a thin layer, and it changes what you optimise.
Recall dominates precision. Missing a clause is a professional failure; surfacing one that turns out not to matter costs ten seconds. Systems tuned for a tidy, confident, short answer are tuned in exactly the wrong direction. Over-retrieve and let the expert discard.
Quote exactly, and verify the quote. Every claim carries the verbatim text and its location — clause number, page, section path. Then check programmatically that the quoted string actually appears in the source. A near-paraphrase presented as a quotation is the single most damaging failure this class of system can produce.
Cross-references have to be followed. Contracts define terms in one place and use them in twenty. "Confidential Information" carries a definition that may itself reference a schedule. A system that reads clauses in isolation will confidently misread any agreement with normal drafting.
Absence is a finding. "There is no limitation of liability clause" is often the most important output, and it is one a retrieval-plus-generation system produces badly by default — because it is generated from what was found, and nothing was found. Checking for expected clauses has to be an explicit pass against a checklist, not an emergent property.
Structure before semantics
Chunking a contract on token count destroys it. Clause 8.3 gets separated from 8.3.1; a definition is severed from its term; a schedule detaches from the clause incorporating it.
Parse the structure first — parties, recitals, numbered clauses and their hierarchy, defined terms, schedules — and let that structure be the retrieval unit. Carry the clause path into every chunk so a retrieved fragment knows where it sits. This is unfashionable document-parsing work and it determines the quality ceiling of everything above it.
The interface is most of the product
Reviewers work in the document, not in a chat window beside it. The output belongs anchored to the text: highlights on the clauses that matter, a panel that jumps to each, the ability to disagree and record why.
And those disagreements are the asset. A reviewer marking a flagged clause as irrelevant, or adding one the system missed, is producing expert-labelled evaluation data. A system that does not capture that is throwing away the only training signal it will ever get for free.
What not to claim
Not that it reviews contracts. It finds and quotes the relevant provisions, checks for expected ones, and shows its working. The judgement — and the liability — stays with the person, and being explicit about that is what makes the tool adoptable rather than something the legal team has to defend.