Skip to content
Solutions · Extraction + RAG

Contract analysis that flags the deviations and leaves the judgement to lawyers

Review every clause against your playbook, pull obligations and dates into a register, and ask questions across the whole repository with citations to the exact paragraph.

  • Playbook-based clause comparison
  • Citations to the paragraph
  • 8–12 weeks to production
The problem

Review is slow, inconsistent and blind to what was signed last year

A supplier agreement arrives and a lawyer reads all forty pages to find the six clauses that matter. Another lawyer, reviewing a similar agreement the same week, reaches a different conclusion on the same limitation of liability wording. Meanwhile, renewal deadlines and notice periods in contracts signed three years ago sit in PDFs nobody opens.

Keyword search cannot find "the clauses where our indemnity cap is lower than standard", because the answer depends on meaning and on comparison. That is a job for clause extraction, retrieval and a model that explains, with the lawyer keeping the decision.

How it works

From incoming agreement to a reviewed position and a live obligations register

Contract analysis workflow: contracts and the playbook feed clause splitting and classification, playbook comparison and obligation extraction; a lawyer confirms flagged deviations while matching clauses are recorded; results go to the contract repository, obligations register and audit log INPUTS AI STEPS HUMAN REVIEW SYSTEMS OF RECORD Incoming contract (Word, PDF, scan) Playbook: standard, fallback, red lines Split into clauses, classify each type Compare to playbook, score deviation Extract obligations, dates, parties, amounts Matches standard: recorded, no action Deviates: lawyer accepts, redlines, rejects no clause is cleared without a person Contract repository Obligations register Audit log
Clauses that match a standard position are recorded automatically; anything that deviates waits for a lawyer. Dates and obligations flow into a register with reminders, and every answer cites the paragraph it came from.

1. Split and classify

The contract is broken into clauses and definitions, each labelled by type: term, termination, liability, indemnity, data protection, payment and so on. Cross-references and defined terms are resolved so a clause is read in context.

2. Compare and extract

Each clause is compared with your playbook position and given a deviation score with an explanation. In parallel, obligations, deadlines, notice periods, amounts and parties are extracted into structured fields.

3. Review, record, ask

Lawyers work a queue of deviations with suggested redlines. Confirmed results update the repository and the obligations register. Anyone with access can then ask questions across the portfolio using hybrid search and get cited answers.

What you get

What the legal team receives

  • Playbook comparison engine

    Your standard positions encoded as a versioned playbook, applied to every clause with a deviation score, an explanation and a suggested redline drawn from your fallback wording.

  • Obligations and dates register

    Renewal dates, notice windows, payment milestones and reporting duties extracted into a register with calendar reminders, each linked to the clause that created it.

  • Cited question answering

    Ask "which active agreements allow assignment without consent" and get a list with the paragraph quoted, built on our document Q&A architecture with matter-level permissions.

  • Review queue with redlines

    A work queue sorted by risk, showing the clause, the playbook position and a proposed redline the lawyer can accept, edit or discard, with the decision recorded.

  • Accuracy reporting

    Clause classification and extraction scored against a lawyer-labelled set on every release, plus portfolio metrics: deviations by clause type, time to review, and backlog.

Guardrails we build in

Accuracy thresholds: clause classification and date extraction must meet agreed targets on your labelled sample before live use, and anything below the confidence threshold is shown as uncertain rather than hidden. Human-in-the-loop: deviations are never cleared automatically; the system records who confirmed each position and when. Audit trail: playbook version, model version, extracted values, citations and reviewer decisions are stored per clause. PII handling and confidentiality: contracts are processed inside your environment or a private deployment in your region, with matter-level access control, following secure RAG architecture. The full control set is described under AI security and governance.

Typical rollout

Playbook first, then one contract type, then the archive

  1. Write the playbook (2 weeks)

    Workshops with the legal team to capture standard positions, fallbacks and red lines for the first contract type, and to label a sample of past agreements.

  2. Build and measure (4–6 weeks)

    Clause splitting, classification, comparison and extraction, tested against the labelled set until targets are met. Question answering is added over the indexed sample.

  3. Supervised pilot (2–4 weeks)

    Lawyers review live contracts through the queue while still reading in full. Agreement rates between the AI and the lawyers decide which clause types are ready.

  4. Backfill and extend (2 weeks)

    The signed archive is processed to populate the register, further contract types are added and the team is trained to maintain the playbook.

Illustrative example

What a first release usually looks like

Illustrative scenario, not a client case

A mid-sized technology company signs a steady stream of customer agreements and supplier contracts, reviewed by a small in-house legal team with outside counsel for the difficult ones. The first release covers inbound supplier agreements. The playbook workshop reveals that the team's positions on liability caps and data-processing terms were never written down, so writing them is the first deliverable. In the supervised pilot, the system clears the clauses that match standard wording and queues the rest, sorted by risk. Lawyers spend their time on the queue instead of reading every page, and the obligations register reveals several auto-renewals that would otherwise have passed unnoticed. The second phase processes the signed archive and adds customer agreements.

For scanned or signed paper contracts, the ingestion step is shared with our document processing solution.

FAQ

Frequently asked questions

Does the AI give legal advice?

No. It finds, classifies and compares clauses against positions your own legal team has written down, and it flags deviations. A qualified person decides what to do about them. The system is designed so that nothing is marked as acceptable without a lawyer's confirmation.

What is a playbook and do we need one?

A playbook is your list of standard positions per clause type: preferred wording, acceptable fallbacks and red lines. Most legal teams have one, often informally. If yours is in people's heads, the first two weeks of the project write it down, which is usually valuable on its own.

Can it work on scanned or signed PDFs?

Yes. Scanned contracts go through the same vision and layout step as our document processing solution before clause analysis. Handwritten amendments and stamps are flagged for a person rather than interpreted.

How is confidentiality protected?

Contracts stay in your environment or in a private model deployment in your chosen region. Retrieval respects matter-level permissions, so a user only gets answers from contracts they may open. The architecture follows our secure RAG architecture and AI data privacy practice.

How long until the legal team can use it?

Eight to twelve weeks is typical: two to write down the playbook and label a sample, four to six for clause classification, extraction and the question-answering layer, and two to four for a supervised pilot on live contracts.

Ready to make AI work in production?

Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.