Contract analysis: the contract as a knowledge model

The problem

Reading a contract out is fast today: parties, term, amounts, deadlines. Whether it is sound, though, is only decided in context. Does the liability cap of the framework agreement apply, or the different one in the purchase order? Did the amendment really change the notice period? Does the clause hold against mandatory law? And who stands behind the counterparty – are there links into one's own organisation? This review is mostly manual work, spread across registers, spreadsheets, e-mails and the memory of experienced people.

The approach

The contract as a knowledge model. Every document becomes a graph: parties, services, obligations, rights, deadlines, conditions and defined terms as nodes; “refers to”, “defines”, “amends” and “takes precedence over” as edges. A reference such as “pursuant to clause 4.2” is resolved, and a definition applies where the contract lets it apply. Every node carries its source.

The layers. A contract’s graph does not stand alone. Individual contract or call-off, framework agreement, annexes and SLA, standard terms and amendments form a stack, and above and below it lies the law – mandatory law as a limit, default law for what the contract leaves open, case law as interpretation. Versions and effective dates show what applied at which point in time.

Precedence as a set of rules. When two layers contradict each other, conflict rules decide: lex superior, lex specialis, lex posterior and the contract’s own order-of-precedence clause. They are data in the model, not a sort order in the code – and because they can collide, the system records for every conflict which rule decided it, or that none did.

External sources. Register and party data and the organisation’s own records are connected. Parties and persons are matched across sources. This makes personal conflicts of interest visible – links to the organisation’s own staff, officers or other counterparties – as well as contradictions between document and source.

Who decides

• The system, by rule – where a precedence rule resolves the conflict unambiguously, with the rule and the source as evidence.
• A human acknowledges – where the outcome is clear but has legal consequences: a clause that fails against mandatory law, a deviation from the framework agreement, a conflict of interest.
• A human weighs – where no rule decides: in interpretation, in good faith, with a clause that may be grossly unfair. The system lays out the positions with their sources.

Integrated into internal workflows. Findings become review tasks and approvals in the existing systems – with ownership, deadline and a complete audit trail. Every decision goes back into the model: who, when, and why.

The result

Fewer blind spots and shorter review times, without handing over the decision. The machine reads, connects and applies rules; where the rules end, people decide – and the system records who decided what and why. With every contract reviewed the model grows, and the next one goes faster.

The thinking behind it is in the Insight “LLM extraction isn’t the hard part – modelling the knowledge in context is”.