Contract review assistant that works from your playbook

A first-pass reviewer for the NDAs, MSAs, order forms and vendor agreements your team sees every week. It works from your own clause playbook, and a lawyer makes every call.

We reply to every inquiry within 1 working day.

Blueprint facts

Build time
8 to 12 weeks
Price band
$20,000 to $40,000
Steps
7
Components
6
Updated

In short

A contract review assistant compares an incoming contract with your clause playbook, lists every clause that deviates from your standard position or is missing, and suggests fallback language that cites the playbook entry it came from. A lawyer reviews and decides every issue. We build it in 8 to 12 weeks for $20,000 to $40,000, starting with 2 or 3 contract types.

Updated

How the parts connect

SourcesWorkflowModelLegal teamLow confidence goes straight to the lawyer01Contract arrivesDrive, inbox or CLM02Split into clausesNumbering keptClause playbookPositions and fallbacks03Classify clausesType and confidence04Compare to playbookMatch, deviate, missing05Suggest fallbacksApproved text only06Lawyer reviewsAccept, edit, reject07Log decisionsQuarterly reviewSourcesWorkflowModelLegal team01Contract arrivesDrive, inbox or CLM02Split into clausesNumbering keptClause playbookPositions and fallbacks03Classify clausesType and confidence04Compare to playbookMatch, deviate, missing05Suggest fallbacksApproved text only06Lawyer reviewsAccept, edit, reject07Log decisionsQuarterly review
Contract review assistantAn incoming contract is split into clauses, a model classifies each clause and compares it with your playbook, fallback language is suggested from approved text, and a lawyer accepts, edits or rejects every point before decisions are logged for the quarterly playbook review.
  • Model step
  • A person decides
  • Exception or feedback path

How it runs, step by step

7 steps, in the order the system runs them.

  1. Step 1

    Contract arrives

    A contract lands in a SharePoint or Google Drive folder, a legal inbox or your contract management tool. The system records counterparty, contract type and requester.

  2. Step 2

    Read and split clauses

    Text is extracted from Word or PDF, with OCR from Azure AI Document Intelligence or AWS Textract for scans. The document is split into clauses with numbering and headings kept.

  3. Step 3

    Classify each clause

    Each clause is tagged with a playbook type such as limitation of liability, indemnity, governing law, auto-renewal or payment terms. Clauses that fit no type, or fall below the confidence threshold, go to the lawyer unchecked.

  4. Step 4

    Compare to the playbook

    Each clause is checked against its playbook entry: standard position, approved fallbacks and walk-away line. Required clauses with no match in the document are listed as missing.

  5. Step 5

    Suggest fallback language

    For each deviation the assistant proposes text from the approved fallbacks, cites the playbook entry ID and explains the gap in 1 or 2 sentences.

  6. Step 6

    Lawyer reviews

    The lawyer works through an issues list and a commented copy of the Word file, accepting, editing or rejecting each point. Only the lawyer sends anything to the counterparty.

  7. Step 7

    Log and update playbook

    Every flag and decision is logged against its playbook entry with the model version used. Positions the lawyer keeps overriding go to the playbook owner at the quarterly review.

What the system is made of

The parts you own at handover, each one written up in the documentation and the runbook.

Clause playbook
Your positions as structured data: clause type, standard text, ranked fallbacks, walk-away line, approver and the reason behind each.
Document reader
Extracts text and structure from DOCX and PDF, with OCR for scans, and keeps clause numbers so every flag points to a location.
Clause classifier
A model call that tags each clause with a playbook type and a confidence score.
Comparison step
Retrieves the matching playbook entry and returns a structured verdict for each clause: matches, deviates or missing, with the reason.
Redline drafter
Builds suggested replacement text from approved fallbacks only and inserts it into a Word copy as comments with the playbook citation.
Review screen
An internal web page listing issues by risk, with accept, edit and reject on each and a link to the clause in context.

What it runs on and what it costs

Runs on

  • Microsoft Word with SharePoint, or Google Drive
  • Azure AI Document Intelligence or AWS Textract for scanned PDFs
  • Anthropic or OpenAI API, or Azure OpenAI and AWS Bedrock for regional hosting
  • Postgres with pgvector for playbook and precedent search
  • n8n or a small Python service for orchestration
  • Ironclad, DocuSign CLM or your current contract repository (optional)
  • Next.js for the internal review screen

Everything is set up on accounts in your name.

Build time and price

$20,000 to $40,000 per project

2 or 3 contract types with a written playbook. Turning an unwritten playbook into one is scoped separately.

Build time
8 to 12 weeks
During the build
A demo of working software every week
Model and tool usage
Billed at cost, no markup
Changes after handover
$175 an hour, or a care plan
See prices for every service

What could go wrong and what stops it

The risks we design for from the first week, and how the build handles each one.

  • A clause the assistant missed

    The assistant reports what it checked, clause by clause, and lists every required playbook entry it could not find. The review screen states that the lawyer still reads the full contract.

  • Fallback language nobody approved

    Suggested text comes only from the playbook's approved fallbacks. If none fits, the assistant says so and leaves drafting to the lawyer. It never writes a new legal position.

  • Confidential terms leaving your control

    Contracts go to model APIs on accounts you own, or to Azure OpenAI or AWS Bedrock in a region you choose. Access to files and results follows your SharePoint or Drive permissions.

  • Instructions hidden in a contract

    A counterparty document could contain text written to steer the model. Output is held to a fixed schema, the assistant has no tool that can send or sign, and every verdict is checked against your playbook.

What goes into a clause playbook?

The playbook is the real asset in this build. It often lives in a senior lawyer's head or a Word file nobody updates, and we turn it into entries the assistant can check against, one per clause type:

FieldExample (limitation of liability, illustrative only)
Standard positionLiability capped at fees paid in the prior 12 months
Fallback 1Cap at 24 months of fees
Fallback 2Separate higher cap for data protection breaches
Walk-awayUncapped liability for the company
ApproverGeneral counsel for anything past fallback 1
ReasonInsurance cover limits and deal size

A typical starting playbook has 15 to 30 entries for one contract type. The reason field matters more than it looks: when the assistant explains a deviation, it quotes the reason, so a commercial manager can understand the flag without calling legal.

If your playbook is not written down, that work comes first: 2 to 4 weeks of a lawyer's time alongside ours, drawing on 20 to 40 recently negotiated contracts. The comparison step uses retrieval-augmented generation to pull the right entry for each clause, which is the same pattern as our RAG and knowledge systems work.

How accurate is it, and how do you test that?

We measure it on your own contracts before launch, and we do not quote an accuracy figure until we have.

During the Prove stage we run the assistant blind on 30 to 50 contracts your lawyers have already reviewed, then compare its issues list with their real redlines. Two numbers matter. Recall: of the issues the lawyer raised, how many did the assistant flag? Precision: of the flags it raised, how many were real issues? For contract review, recall matters more, because a missed issue costs more than a false flag a lawyer dismisses in 10 seconds.

You set the launch bar with us in the Map stage, per clause type. Types that miss it stay in manual review, labeled that way in the issues list, while the rest go live. Expect a split: governing law is easier to check than indemnity wording, which varies more and needs more examples.

After launch the audit log becomes a growing test set. Every lawyer override is a labeled example, and we rerun the full set before any prompt or model change. This is standard LLM evaluation practice, and it is the core of our AI ops monitoring service.

What does a contract review assistant cost to build and run?

The build is a fixed price from $20,000 to $40,000. The low end covers 2 contract types on your paper and the counterparty's, a written playbook, SharePoint or Drive intake and the review screen. Price rises with more contract types, scanned documents that need OCR, integration with a contract management tool such as Ironclad or DocuSign CLM, and regional hosting requirements.

Running costs are billed at cost with no markup. Model usage depends on contract length and clause count. A 20-page MSA with 40 clauses is usually a few dollars or less to review at current API prices, and an NDA costs a fraction of that. OCR services charge per page, so mostly digital contracts keep that line small. Hosting the review screen and database is a small monthly server bill.

The cost that needs a budget is upkeep. Playbook positions change, new contract types appear and model versions get retired by providers. AI ops monitoring at $1,500 to $5,000 a month covers evaluation reruns, prompt fixes and model upgrades. A team with an in-house legal operations person can run it after handover using the runbook.

When should you buy a tool instead of building this?

When your contracts are standard and your lawyers work in Word. Commercial tools such as Spellbook and Luminance review contracts inside or alongside Word, and contract platforms such as Ironclad include AI review features. For a team reviewing mainly NDAs and standard MSAs, a subscription usually costs less than a build and starts working sooner.

A custom build makes sense when your playbook is specific enough that generic tools flag the wrong things, when contracts move through your own systems and you want results there, or when data must stay on your accounts in a region you choose. Microsoft's data terms for models hosted on Azure (opens in a new tab) state that prompts and completions are not used to train the models, which is often what a general counsel asks first. Volume matters too: below roughly 20 contracts a month, the time saved rarely pays back a build within a year.

It is the wrong tool for one-off, high-stakes deals such as acquisitions, where no playbook applies. It is also the wrong tool when no lawyer will own the playbook. Without an owner, positions go stale and the assistant enforces last year's view.

We make this call with you during an AI readiness audit or the Map stage of an intelligent document processing engagement. If buying wins, we say so.

Common questions about this build

The full FAQ covers pricing, ownership, data and timelines.

Does a contract review assistant replace our lawyer?

No. It does the first pass: finding each clause, comparing it with your playbook and drafting fallback text from positions your lawyers already approved. A lawyer reads the contract, decides every issue and sends anything that goes to the counterparty. The lawyer's time goes to the clauses that need judgment, because the boilerplate check is done before they open the file.

Which contract types should we start with?

The ones you see most often with the most predictable terms. NDAs, vendor agreements, order forms and MSAs are the usual first choices because they repeat weekly and the playbook positions are clear. Start with 2 or 3 types, prove accuracy on those, then add more, each with its own playbook entries and test contracts.

Does it work inside Microsoft Word?

The standard build returns a copy of the Word file with each issue as a comment beside the clause, plus an issues list in the review screen. A Word add-in that runs the review from the ribbon is possible and is scoped separately, because it adds Microsoft 365 deployment work.

Is our contract data used to train AI models?

Not by this build. Model calls go through API accounts you own with OpenAI or Anthropic, or through Azure OpenAI or AWS Bedrock, and these providers state that API inputs are not used to train their models by default. We confirm current terms and residency needs before the first contract is processed.

What if we do not have a written playbook?

Then writing one is the first deliverable. A lawyer from your side works with us for 2 to 4 weeks, using 20 to 40 recently negotiated contracts to record standard positions, fallbacks and walk-away lines. It is priced separately from the build and is useful on its own for training junior staff.

Price your version of this system

Bring your tools and volumes to a 30-minute call. If a simpler build would do the job, we'll say so.

Request a 30-minute scoping call

Scope and price arrive in writing within 5 working days of the call.