Why Contract AI Needs a Graph, Not Just a Search Box

Ask a contract AI when an agreement renews, and it will tell you. The question worth asking is how it knows.

Most contract search works by cutting documents into passages, embedding them, and returning whichever passage looks most like the question. For a single self-contained agreement this is fine. For a real contract estate it fails in a way that is difficult to notice, because the failure looks exactly like success.

The problem is that contracts refer to other contracts

A master services agreement is signed. Eighteen months later an amendment changes the notice period from ninety days to thirty. A side letter the following year carves out one business unit from that change. The operative notice period now depends on which entity you are asking about, and it is not written in any single document.

Passage-based retrieval will find the master agreement. It is the longest, most contract-shaped document, it uses the phrase "notice period" in a clause explicitly about notice periods, and it will score highest on almost any similarity measure. The amendment, which says something terse like "Clause 14.2 is deleted and replaced with the following", looks much less like the question.

So the system returns ninety days. It is wrong, it cites a real clause from a real executed contract, and there is nothing in the answer to suggest anything is missing.

This is the central difficulty with retrieval over legal documents. A wrong answer does not arrive looking wrong. It arrives with a citation.

What a graph changes

Modelling the estate as a graph means storing the relationships between documents as first-class facts rather than hoping they are recoverable from the text. Agreement, amendment, side letter, order form, statement of work — each a node, with edges recording what amends what, what incorporates what by reference, and what supersedes what and from when.

A question about a notice period then becomes a traversal rather than a similarity search. Find the agreement governing this entity, follow every amendment edge in date order, apply the carve-outs, and return the term that is actually in force — with the full chain, so a lawyer can see how the answer was reached and check it.

The difference is not marginal accuracy. It is whether the system is answering the question at all.

Recall matters more than fluency

There is a temptation to tune these systems for good-sounding answers. In contract work that is precisely the wrong objective.

A missed uncapped indemnity costs more than a hundred over-cautious flags. A summary that reads well but silently omits a superseded clause is worse than a blunt answer that admits uncertainty. So the system is built to prefer surfacing too much: where the chain is ambiguous, it says so and shows what it found rather than picking the most plausible branch.

The same reasoning drives the rule that every answer carries its clause. Not a paraphrase, not a summary — the text, from the document, with the reference. An assertion without a citation cannot be used in legal work, so producing one is wasted effort no matter how accurate it happens to be.

What it does not do

It does not advise. It extracts, cites and flags: obligations, dates, caps, unusual terms, things that differ from the standard position. What any of that means for a negotiating position is a judgement, and it belongs to the lawyers.

That boundary is worth stating explicitly in the system rather than assuming it. A model asked what a clause means will answer, confidently, because that is what models do. Being built not to is a design decision that has to be made and enforced.

Where the data lives

Contract estates are among the most sensitive document sets an organisation holds, and most legal teams will not send them to an external service — reasonably.

Open-weight models make this practical. The full stack — retrieval, models and governance — runs inside your own infrastructure, with nothing transmitted outside. The capability cost of that choice is now small enough that it rarely decides the architecture.

---

We build contract lifecycle intelligence this way at iLeaf, and the CLM system is running rather than described in a slide — worth twenty minutes with your own awkward document set, which is the only test that means anything.