AI prototype
Every clause gets a human verdict
Contract review is the most demoed AI use case in the enterprise and the least trusted. I built the version where the model proposes a redline and a lawyer accepts, edits or rejects each one.
- Real contract types, not one cherry-picked document
- 4 scenariosReal contract types, not one cherry-picked document
- The model returns machine-readable findings, not prose to re-read
- Structured outputThe model returns machine-readable findings, not prose to re-read
- Accept, edit or reject on every proposed change
- Per-clause decisionAccept, edit or reject on every proposed change
The client
A European mobile network operator with a legal function reviewing high volumes of recurring contracts — site leases, vendor service agreements, roaming agreements and bulk compliance checks — in two working languages.
The engagement
A presale prototype covering four real contract scenarios end to end, with the model wired live rather than scripted.
A working demo of this build exists.
It is not public yet — ask for access, and where the NDA allows I will send a link or walk you through it on a call.
The problem
Legal AI demos fail in a specific way: the model produces a fluent summary, everyone nods, and nobody can say what the lawyer is supposed to do next. A summary is not a work product. And the second failure is scope theatre — one carefully chosen contract that the model happens to handle well, which tells the buyer nothing about their actual document mix.
What I did
I made the output a decision queue rather than a document. The model is constrained to return structured findings rather than prose, which is what allows each risk and each proposed redline to become a row a lawyer can accept, edit or reject — so the artefact leaving the tool is a reviewed redline with a named human behind every change, not a machine opinion. Four genuinely different contract types were prepared rather than one, because the interesting question is where the approach degrades. And I wrote down the demo's own compromise honestly: the prototype calls the model directly from the browser, which is fine for a demonstration and unacceptable in production, where the call belongs behind a backend. Saying that out loud in a legal-department room buys more credibility than hiding it.
What was built
Document upload and parsing in the browser for the common formats, structured analysis from the model in a strict machine-readable mode rather than as prose, output as a risk list and a proposed redline against a checklist, and an accept-edit-reject decision on every single item, across four prepared scenarios and two interface languages.
On the table at the end
- Working prototype with live model analysis over uploaded documents
- Four contract scenarios: site lease risk, vendor service level, bulk compliance, roaming agreement
- Redline and checklist output with per-item human decision
- Written note on what the demo compromises and what production would require
What it changed
Moved the conversation from 'can AI read a contract' — which everyone assumes — to 'what does the lawyer do with the output', which is where these programmes actually succeed or die.
How it ran
- 01
Make the output structured
The model constrained to machine-readable findings rather than prose, so every result can become an actionable row.
- 02
Build the decision queue
Risks and redlines presented as items with accept, edit or reject — the reviewed output carries a human behind each change.
- 03
Cover four document types
Site lease, vendor service level, bulk compliance and roaming — chosen to expose where the approach gets harder.
- 04
Parse where it is cheapest
Documents parsed in the browser, so the demo runs anywhere without an ingestion backend to stand up first.
- 05
State the compromise
Direct model calls from the browser named as a demo-only shortcut, with the production shape described rather than implied.
Other work
All case studies →- Document operations
When the prototype needs a database
Most presale demos are a front end pretending. This one had to survive a login, an upload and a restart — so I built the backend too.
- Delivery operations
A knowledge pipeline that pages someone
Every organisation has a knowledge base nobody reads. I built the version that reads itself, notices a slipping deadline or a budget breach, and messages a person — and exposes the same data to the assistant in the editor.
- Investment holding
Presenting the build-versus-buy fork before anyone fell in love with building
A multi-entity holding wanted document AI across its finance operations. I designed the pipeline and then showed them the packaged alternative honestly, including where it would beat us.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.