AI Contract Review for Law Firms: LPA Analysis Case Study

The client is a UK firm whose fund lawyers review Limited Partnership Agreements. Investment fund lawyers spend 4-6 hours per LPA manually reviewing 150-200 page documents, hunting for key clauses buried across dozens of sections. They cross-reference definitions scattered throughout the agreement, compare terms against market standards from memory, and flag risks based on years of pattern recognition. When a fund is raising capital, a single lawyer might review 10-20 LPAs in a month - that's 40-120 hours of dense, repetitive analytical work.

The firm needed a system that could read an entire LPA, extract the clauses that matter, analyse them against market standards and surface risks - without the lawyer ever leaving Microsoft Word. Not a generic document chatbot: a purpose-built legal analysis engine that understands investment fund terminology, cross-references and the clause categories that drive negotiations.

The short version

The system takes a 150-200 page Limited Partnership Agreement as a Word file, finds every clause in six categories that drive fund negotiations, and gives the lawyer a plain-English summary, a detailed analysis against market standards, the defined terms involved and suggested drafting - each tied back to its place in the document. It works inside Microsoft Word as an add-in, uses zero-retention AI processing, and takes a review that used to cost 4-6 hours down to minutes.

If you are a law firm, a legal-tech team building contract review or a fund team that reads LPAs at volume, the parts worth copying are below: how long agreements are parsed without breaking clauses, how extraction is made complete enough to trust, how the analysis cites its sources, and how client documents are kept out of third-party AI services.

What I Built

A production AI legal analysis platform for reviewing Limited Partnership Agreements. Two interfaces - a web dashboard for document management and a Microsoft Word Add-in for in-document analysis - powered by one RAG backend that draws on the firm's own document library.

The core challenge: legal documents aren't like blog posts or emails. A single clause can span 3 pages, reference 15 defined terms from other sections, and contain nested exceptions that completely change its meaning. The system had to parse document structure intelligently, chunk without breaking legal context, and deliver analysis that a senior fund lawyer would trust enough to use in client negotiations.

The 3 Core Systems

1. Intelligent Document Processing Engine

Takes a raw .docx LPA (150-200 pages), parses its structure, and extracts every instance of 6 critical clause categories with confidence scoring.

The pipeline starts with TOC extraction using 4 regex patterns to map the document's structure. A structure analyser identifies section boundaries, headings and clause-type hints. Smart chunking then splits the document into ~4,000-character segments that respect section boundaries - never cutting a clause mid-sentence. Each chunk is queued as an independent background job via QStash, so 100+ chunks process in parallel across serverless functions.

A two-pass extraction strategy maximises recall: Phase 1 uses TOC navigation for targeted extraction from likely sections (high confidence). Phase 2 performs comprehensive fallback extraction for anything missed, including oversized sections (>15,000 chars) that Phase 1 intentionally skips for speed.

Result: upload a 200-page LPA, and a few minutes later every Key Person clause, GP Removal provision and Waterfall distribution term the two passes found is extracted, categorised, scored and ready for analysis - without anyone paging through the document to find them.

2. RAG-Powered Clause Analysis

Takes any extracted clause and generates a 4-part legal analysis, using the firm's entire LPA library as context.

When a lawyer clicks “Analyse” on a clause, the system checks the analysis cache (SHA-256 hash of clause text, 7-day TTL). On a cache miss, it calls a Dify workflow that queries the Knowledge Base (top-k: 10 chunks from the firm's LPA corpus). GPT-4o generates a structured analysis with cross-document context, parsed into 4 sections and cached for future use.

The 4-part analysis framework was designed around how senior fund lawyers actually think:

Summary: 2-3 sentences in plain English with section citations - what a partner would say in a 30-second brief
Detailed Analysis: thresholds, triggers, consequences and fully unpacked cross-references - the substance a senior associate needs
Key Considerations: market standard comparison (e.g. “GP removal typically requires 50-75% LP vote”), LP vs GP favourability, negotiation leverage points and red flags
Definitions: every defined term referenced in the clause, with full definitions and source locations from the LPA

Each clause type has calibrated focus areas. For Waterfall clauses, the system benchmarks against typical 8% hurdle rates and 80/20 LP/GP carried interest splits. For Key Person clauses, it evaluates time commitment requirements and replacement procedures. For GP Removal, it flags voting thresholds outside the 50-75% market standard.

What this means in practice: you don't just see that a GP Removal clause exists. If it requires an 80% LP vote, you see that this is above the market standard; if it has no cure period, you see that this is unusual; and if the consequences don't address carried interest on existing deals, you see the gap before the other side's counsel does. In seconds, not hours.

3. Microsoft Word Add-in

Brings the analysis directly into the lawyer's document - no tab switching, no copy-pasting, no workflow disruption.

Built with Office.js and React, the Add-in installs as a sidebar panel in Microsoft Word on Windows and Mac. When a lawyer opens an LPA, they click “Analyse” and the plugin extracts the full document text, sends it to the backend, and renders results in a panel grouped by clause category.

Each clause category gets a distinct colour:

Key Person (Yellow): time commitments, named individuals, replacement triggers
GP Removal (Blue): voting thresholds, cause definitions, cure periods
Term & Termination (Green): partnership term, extension mechanics, dissolution events
Waterfall (Purple): distribution priorities, hurdle rates, catch-up provisions
Clawback (Red): trigger events, calculation methods, escrow requirements
LPAC (Grey): committee composition, conflict resolution, advisory powers

Click any clause in the sidebar, and the plugin navigates to its exact location in the document with highlighting applied. Expand a clause for one-click access to AI analysis, drafting suggestions and cross-document context - all rendered inline without leaving Word.

How accuracy is checked

A legal AI tool is only useful if a lawyer can see why it said what it said. Rather than ask anyone to trust the output, the system is built so every result can be checked against the agreement itself:

Confidence scores on every extracted clause. Clauses found through TOC navigation in their expected sections are marked high confidence; the lawyer can see which results deserve a closer look.
A second pass for completeness. The fallback extraction pass exists specifically to catch clauses the targeted pass missed, including those in oversized sections.
No half-clauses. TOC-aware chunking keeps each provision whole and close to its context, so the model never analyses half a clause.
Citations back to the source. Summaries cite the sections they draw on, every defined term comes with its source location, and results carry page references.
Human review in Word. Every clause in the sidebar jumps to its exact place in the document with highlighting, so the lawyer reads the analysis next to the original language before relying on it.

This system was built for one firm's documents, and I don't publish a headline accuracy figure for it. For measured retrieval numbers on public data, the closest thing I can point to is my own product SureCiteAI, which has a 94% retrieval hit-rate across six benchmark suites, one of them the CUAD legal contract suite.

Architecture

The web dashboard and Word Add-in share the same API layer and RAG backend. When a document is uploaded through the dashboard, it's simultaneously indexed in the Dify Knowledge Base, making its content available for cross-document analysis via the Word plugin. Every query - whether from the web UI or Word - passes through the same multi-tenant isolation layer, analysis cache and quality validation pipeline.

QStash handles the heavy lifting asynchronously: document uploads queue parallel chunk-processing jobs that execute across Vercel's serverless infrastructure, with real-time progress updates written atomically to the database. The lawyer sees a live progress bar while 100+ extraction jobs run in parallel behind the scenes.

Technical Decisions Worth Noting

Why parallel chunk processing over sequential: a 200-page LPA produces ~50 chunks at 4,000 chars each. Sequential processing would take 25-50 minutes (30-60s per Dify workflow call). Parallel processing via QStash completes the same work in minutes. The trade-off is infrastructure complexity - atomic progress tracking, deduplication logic and rate-limit management - but the difference for the user is dramatic.

Why a Microsoft Word Add-in over a standalone web app: lawyers live in Word. An analysis tool that requires copying text into a browser, waiting for results, then switching back is dead on arrival. The Add-in keeps the clause, the surrounding language, the analysis and the drafting suggestions in one view. The tool meets the user where they already are.

Why TOC-aware chunking over naive splitting: naive text splitting (every N characters) routinely breaks clauses mid-sentence or separates a provision from its definitions. TOC-aware chunking maps the document's logical structure first, then creates chunks that respect section boundaries. Each chunk contains a complete legal thought.

Why multi-tenant isolation at the database level: for a system handling confidential legal documents across multiple law firm teams, I chose explicit organisation_id enforcement on every table, every query and every index. Composite indexes starting with organisation_id keep tenant-scoped queries on index scans, not sequential scans. CASCADE deletes give clean data removal when a tenant leaves. Defence in depth for data that cannot leak.

Why Dify Cloud over a custom RAG pipeline: Dify provides workflow orchestration, knowledge base management, model routing and zero-retention processing out of the box. Building this from scratch would add 4-6 weeks to the timeline for infrastructure that doesn't differentiate the product. The value is in the legal domain logic - the prompts, the clause-type calibration, the market-standard benchmarking - not the vector database plumbing.

Key Results

70%+ of manual LPA review time eliminated. 4-6 hours per document reduced to minutes with parallel processing.

6 critical clause types extracted automatically - Key Person, GP Removal, Waterfall, Clawback, Term & Termination, LPAC - with confidence scoring and page references, in a design that can grow to 20 clause types.

100+ parallel chunk processing jobs via QStash across Vercel serverless - two-pass extraction with TOC-aware parsing for maximum recall.

RAG pipeline with Dify Cloud + pgvector retrieves cross-document context from the firm's full LPA corpus (top-k: 10 chunks).

~60% API cost reduction on repeat queries through 7-day caching keyed on a SHA-256 hash of the clause text.

AI-generated drafting suggestions with issue identification, recommended language and legal rationale - prioritised by severity (critical, high, medium, low).

Zero-retention AI processing across all LLM providers - no client documents stored by third-party AI services, meeting law firm data governance requirements.

Security & Compliance

Multi-tenant data isolation with organisation-scoped queries on all 11 tables. Zero-retention configuration across all LLM providers. Clerk authentication with SSO, MFA and organisation management. Full audit trail with user, resource and timestamp tracking. TLS in transit, encrypted at rest. Role-based access control (admin, member, viewer) per organisation. QStash signature verification and CORS enforcement on all API routes.

What an assessment of your legal AI covers

If you are building or buying AI that reads legal agreements, you are usually at one of two points: you already have a system or prototype and need to know whether it holds up, or you want one and need to know what it would take. The questions are the same ones this build had to answer.

Reviewing a legal AI system or prototype you already have

The AI security and architecture review starts from £2,000 and takes 1-4 weeks, at a price fixed in writing before work starts. For a system that reads legal agreements, it looks at:

Retrieval: whether chunking breaks clauses or separates provisions from their definitions, and whether the right passages come back from long agreements.
Extraction completeness: whether anything checks for clauses the first pass missed, and whether confidence scores mean anything.
Citations: whether every answer points to a source passage a lawyer can check, or asks to be taken on trust.
Data handling: retention settings with every model provider, isolation between clients and teams in the database and the vector store, access control and the audit trail a firm's risk team will ask for.

Scoping a new one

A discovery sprint is 2 weeks from £2,450. It fixes the document type, the clause set and where the tool has to live (Word, a web app or your own product), and ends with a working prototype on your real documents, an architecture document, an evaluation set with a pass mark and a fixed build estimate.

What sets the cost of a build: how many clause types have to be extracted, how varied the source documents are, and how deeply it integrates with the tools the team already uses. Builds are quoted to that scope after the discovery sprint. Monthly operating cost for this system: ~$150-300 for all AI APIs, database and hosting combined. Time recovered: at 4-6 hours saved per LPA review, a team reviewing 10-20 LPAs a month gets back 40-120 hours of associate time.

Where else the same architecture applies

Any document-heavy practice that reviews long-form agreements (M&A, real estate, insurance, compliance)
Any regulated industry requiring zero-retention AI processing and full audit trails
Any professional services firm where analysts spend hours on pattern recognition that AI can accelerate
Any team that needs AI built into tools it already uses (Word, Excel, Outlook) rather than another platform to adopt

Tech Stack

AI/LLM: Dify Cloud (GPT-4o, multi-model routing), OpenAI Embeddings (ada-002), pgvector
Framework: Next.js 15, React 19, TypeScript, App Router
Database: Neon PostgreSQL, pgvector (1536-dim, IVFFlat indexing), multi-tenant schema
UI: Tailwind CSS, Radix UI, Framer Motion, next-themes
Word Plugin: Office.js, React, TypeScript, Webpack
Auth: Clerk (SSO, organisation management, webhook sync)
Background Jobs: QStash (Upstash) with retry logic and rate limiting
Document Processing: Mammoth (.docx parser), custom structure analyser, targeted extractor
Deployment: Vercel (edge + serverless), Neon (managed PostgreSQL)
Security: zero-retention AI, multi-tenant isolation, audit logging, HTTPS-only

Frequently asked questions

Can AI review a Limited Partnership Agreement reliably?

It can find, organise and explain the clauses that matter, and it can show its working. In this system every extracted clause carries a confidence score, a second extraction pass looks for anything the first pass missed, each summary cites the sections it draws on, and every clause in the Word sidebar jumps to its exact place in the document with highlighting, so the lawyer checks the analysis against the source text. The lawyer still reads and decides; the system takes out the hunting and cross-referencing.

How long does AI take to review an LPA?

A 150-200 page LPA is processed in minutes, against 4-6 hours of manual review per agreement. A 200-page LPA is split into about 50 chunks of ~4,000 characters that respect section boundaries, and each chunk is queued as its own background job, with 100+ jobs able to run in parallel. Processed one after another, the same work would take 25-50 minutes.

Are client documents kept by the AI providers?

No. Zero-retention processing is configured across all the LLM providers, so no client documents are stored by third-party AI services. Inside the platform, every one of the 11 database tables is scoped by organisation, sign-in runs through SSO and MFA, access is role-based (admin, member, viewer) and a full audit trail records user, resource and timestamp.

Does the same approach work for other legal agreements?

The pipeline does: structure-aware parsing, parallel extraction, retrieval over the firm’s own document library and analysis inside Word apply to any long-form agreement, such as M&A, real estate or insurance documents. The six clause categories and their market benchmarks are specific to fund LPAs, and the design allows the clause set to grow to 20 types. A new document type needs its own clause set and calibration, which is what a discovery sprint scopes.

Related reading: for how firms can adopt AI more broadly, see AI for law firms: a practical implementation guide. If you are choosing who to hire for AI in a regulated setting, read AI consultants for regulated industries. For the retrieval patterns behind this system, see my production guide to RAG architecture, and for the measured benchmark of my own RAG product, the SureCiteAI case study. The evidence behind the claims on this site is collected on the proof page.

I provide AI architecture, consulting and custom AI development to businesses in the UK, the US and Europe. To build a similar system, see custom AI development in the UK or the US. View all services.