Building a Production-Grade Contract Review System with the Claude API — Risk Detection, Version Diffing, and Remediation Suggestions

PDF Parsing — When to Use pdfplumber and When to Use Claude Vision

Contract PDFs come in two flavors: text-embedded and scanned-image. The first is fine with pdfplumber. The second needs OCR. Rather than wiring in a separate OCR engine, I send scanned pages to Claude Vision as images — the quality and the implementation cost both come out ahead. The trade-off is API cost: Vision adds roughly $0.01–0.03 per page in token usage, which is negligible against the legal team time you save but worth noting if you're processing thousands of pages a day.

The detection is simple: extract with pdfplumber first, and if the average characters per page is below a threshold, treat it as scanned.

# contract_loader.py
# Solves: auto-detect text-embedded vs. scanned PDFs and route them
# to the appropriate extraction path.
import base64
import pdfplumber
from pathlib import Path
from anthropic import Anthropic
 
client = Anthropic()
TEXT_THRESHOLD = 100  # < 100 chars/page average → treated as scanned
 
def extract_text_pages(pdf_path: Path) -> list[str]:
    """Extract from text-embedded PDFs. Returns [] on failure."""
    pages: list[str] = []
    try:
        with pdfplumber.open(pdf_path) as pdf:
            for page in pdf.pages:
                text = page.extract_text() or ""
                pages.append(text)
    except Exception as e:
        # Treat broken PDFs as scanned at the upper layer
        print(f"[loader] pdfplumber failed: {e}")
        return []
    return pages
 
def is_scanned(pages: list[str]) -> bool:
    if not pages:
        return True
    avg = sum(len(p) for p in pages) / len(pages)
    return avg < TEXT_THRESHOLD
 
def extract_via_vision(pdf_path: Path) -> list[str]:
    """OCR scanned PDFs page-by-page through Claude Vision."""
    import fitz  # PyMuPDF
    pages: list[str] = []
    doc = fitz.open(pdf_path)
    for i, page in enumerate(doc):
        pix = page.get_pixmap(dpi=200)
        b64 = base64.b64encode(pix.tobytes("png")).decode()
        try:
            resp = client.messages.create(
                model="claude-sonnet-4-6",
                max_tokens=4000,
                messages=[{
                    "role": "user",
                    "content": [
                        {"type": "image", "source": {
                            "type": "base64", "media_type": "image/png", "data": b64,
                        }},
                        {"type": "text", "text": "Transcribe this page faithfully. Preserve layout. Reproduce tables with '|' separators. Do not add any commentary."},
                    ],
                }],
            )
            pages.append(resp.content[0].text)
        except Exception as e:
            print(f"[loader] vision failed on page {i}: {e}")
            pages.append("")
    return pages
 
def load_contract(pdf_path: Path) -> list[str]:
    """Returns: list of page texts."""
    pages = extract_text_pages(pdf_path)
    if is_scanned(pages):
        print("[loader] scanned PDF detected, falling back to Vision")
        pages = extract_via_vision(pdf_path)
    return pages
 
if __name__ == "__main__":
    p = Path("samples/nda_v3.pdf")
    pages = load_contract(p)
    print(f"loaded {len(pages)} pages, total {sum(len(x) for x in pages)} chars")
# Sample output: loaded 12 pages, total 28433 chars

The critical design choice here is keeping the Vision prompt scoped strictly to "faithful transcription." If you let OCR and semantic analysis happen in the same call, Claude starts paraphrasing or summarizing — and downstream clause-level quoting falls apart. I missed this on my first iteration and ended up with risk findings that quoted text not present in the actual contract. Always split OCR and analysis into separate calls.

A second design choice worth flagging is the 200 DPI rendering. Lower DPIs (96, 150) save tokens but lose accuracy on small fonts in tables and footnotes — exactly where contract risk often hides. Higher DPIs (300+) cost more without measurable accuracy gain in my testing. 200 DPI is the sweet spot for letter-size and A4 contracts; you may need to bump to 300 for older scanned documents with degraded print quality.

For PDFs with mixed pages — say, a text-embedded contract with a scanned amendment stapled on — process pages individually rather than the whole document at once. Each page goes through is_scanned-style detection and is routed independently. This adds a few lines but covers the case that breaks naive implementations the moment a real-world document arrives.

Clause Segmentation with JSON-Schema-Validated Output

Splitting a contract into clauses is more robust when you let Claude do the splitting and validate the result with a JSON Schema, rather than wrestling with regex. Define the schema with pydantic and retry up to twice if the output doesn't validate.

# clause_splitter.py
# Solves: turn page arrays into a list of structured clauses with stable IDs.
from pydantic import BaseModel, Field, ValidationError
from anthropic import Anthropic
import json
 
client = Anthropic()
 
class Clause(BaseModel):
    clause_id: str = Field(..., description="e.g., 'Section 3.2'")
    title: str
    body: str
    page_range: list[int]
 
class ClauseList(BaseModel):
    clauses: list[Clause]
 
SPLIT_PROMPT = """You are an assistant that structures legal documents.
Split the input contract text into clauses and return JSON in this schema.
 
Schema:
{
  "clauses": [
    {"clause_id": "Section N.M", "title": "clause title", "body": "verbatim text", "page_range": [start, end]}
  ]
}
 
Rules:
- Body must be the verbatim text. Summarizing or paraphrasing is forbidden.
- If a clause has no number, assign 'paragraph-N' in document order.
- Do not include cover pages, table of contents, or signature blocks.
- Output JSON only — no surrounding prose."""
 
def split_into_clauses(pages: list[str], max_retry: int = 2) -> ClauseList:
    joined = "\n".join(f"[Page {i+1}]\n{p}" for i, p in enumerate(pages))
    last_err = ""
    for attempt in range(max_retry + 1):
        prompt = SPLIT_PROMPT
        if last_err:
            prompt += f"\n\nThe previous output was rejected because: {last_err}\nPlease output again."
        resp = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=8000,
            messages=[
                {"role": "user", "content": prompt + "\n\n[Contract text]\n" + joined},
            ],
        )
        raw = resp.content[0].text.strip()
        # Strip code-fence decoration
        if raw.startswith("```"):
            raw = raw.split("```")[1].lstrip("json\n").rstrip()
        try:
            return ClauseList.model_validate_json(raw)
        except (ValidationError, json.JSONDecodeError) as e:
            last_err = str(e)[:300]
            print(f"[splitter] attempt {attempt+1} failed: {last_err}")
    raise RuntimeError(f"Clause splitting failed after {max_retry+1} attempts: {last_err}")
 
if __name__ == "__main__":
    pages = ["This Agreement…", "Section 1 (Definitions) In this Agreement…", "Section 2 (Confidentiality) The Recipient…"]
    result = split_into_clauses(pages)
    for c in result.clauses:
        print(f"{c.clause_id}: {c.title} (pages {c.page_range})")
# Sample output:
# Section 1: Definitions (pages [1, 1])
# Section 2: Confidentiality (pages [1, 2])

pydantic's model_validate_json catches both shape errors and type mismatches in a single pass. Feeding the validation error back into the next call as a "self-healing loop" works extraordinarily well with conversational models like Claude — in practice, 99% of cases recover by attempt three. Regeneration isn't free, so max_retry=2 is the sweet spot between cost and reliability for production.

A subtle point about the schema: notice that body is a string and page_range is a list of integers. Resist the temptation to add nested structures like subclauses or references_to_other_clauses at this stage. Every additional field is another shape Claude can get wrong, and every wrong shape costs you a retry. Keep the segmentation schema flat and minimal; layer enrichment happens in the analysis layer where the cost of partial output is much lower.

If your contracts use Roman numeral clause IDs (Section I.A.3) or non-standard numbering, document the convention in the prompt rather than fighting it with regex. Claude handles arbitrary numbering schemes well as long as you specify the format. The one place where this breaks is contracts in mixed languages — Japanese legal documents that switch between 第三条 and Section 3 in the same paragraph confuse the model. For those cases, do an explicit normalization pass before segmentation.

One implementation note that saves debugging time later: assign each clause a deterministic surrogate key in addition to the human-readable clause_id. Use SHA256(contract_id + clause_id + body[:100]) truncated to 12 hex chars. This surrogate stays stable as long as the clause body is roughly the same, which is exactly the property you want for caching analysis results across re-runs. The human-readable ID is what you show legal; the surrogate is what your cache and database use as a primary key.

Designing the Risk-Detection Prompt

Once clauses are segmented, the actual risk analysis begins. The trap most teams fall into here is sending vague prompts like "list any risks." Claude is helpful, so it always answers — but the criteria drift call-to-call, and review results stop being reproducible. Two reviewers running the same prompt will get meaningfully different findings; the same reviewer running it twice will get findings that differ in 30–40% of cases. That's fatal in legal-tech, where reproducibility is part of the trust contract with counsel.

The pattern that holds up in production is to fix the risk taxonomy and severity levels in advance. Negotiate with legal to land on roughly 8 categories × 3 levels (low/medium/high), then prohibit Claude from inventing categories outside that list.

# risk_analyzer.py
# Solves: classify each clause as (risk category × level) with required rationale and quote.
from pydantic import BaseModel, Field
from typing import Literal
from anthropic import Anthropic
 
client = Anthropic()
 
RiskCategory = Literal[
    "liability_cap",      # Cap on damages
    "indemnification",    # Indemnity obligations
    "ip_assignment",      # IP rights / assignment
    "termination",        # Termination terms
    "confidentiality",    # Scope/duration of confidentiality
    "governing_law",      # Governing law / jurisdiction
    "data_protection",    # Data protection / privacy
    "auto_renewal",       # Auto-renewal provisions
]
RiskLevel = Literal["low", "medium", "high"]
 
class RiskFinding(BaseModel):
    clause_id: str
    category: RiskCategory
    level: RiskLevel
    rationale: str = Field(..., description="<= 200 chars explaining the basis")
    quote: str = Field(..., description="Verbatim excerpt that supports the finding")
 
class ClauseAnalysis(BaseModel):
    clause_id: str
    findings: list[RiskFinding]
 
ANALYZE_PROMPT_TEMPLATE = """You are a contract risk auditor. Analyze the following clause and return JSON.
 
[Allowed risk categories]
- liability_cap: damages cap is materially unfavorable to the buyer
- indemnification: excessive or asymmetric indemnity obligations
- ip_assignment: blanket IP assignment or perpetual license
- termination: unilateral / immediate termination or punitive fees
- confidentiality: scope or duration is unreasonable
- governing_law: unfavorable choice of law or forum
- data_protection: provisions inconsistent with GDPR / privacy laws
- auto_renewal: short notice period or price-changing auto-renewal
 
[Output schema]
{
  "clause_id": "<clause id>",
  "findings": [
    {
      "clause_id": "<same as above>",
      "category": "<one of the 8 allowed categories>",
      "level": "low|medium|high",
      "rationale": "<= 200 chars",
      "quote": "verbatim excerpt"
    }
  ]
}
 
[Rules]
- If no risks are found, return findings: []
- Stay strictly within the 8 categories. Do not invent new ones.
- The quote must be a verbatim excerpt. No paraphrasing.
- Output JSON only."""
 
def analyze_clause(clause_id: str, body: str) -> ClauseAnalysis:
    resp = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=2000,
        messages=[{
            "role": "user",
            "content": ANALYZE_PROMPT_TEMPLATE + f"\n\n[Clause]\nclause_id: {clause_id}\nbody:\n{body}",
        }],
    )
    raw = resp.content[0].text.strip()
    if raw.startswith("```"):
        raw = raw.split("```")[1].lstrip("json\n").rstrip()
    return ClauseAnalysis.model_validate_json(raw)

The key design choice in this prompt is making quote mandatory. Forcing Claude to quote the supporting text dramatically reduces hallucination. Downstream you can verify that the quote actually appears in the clause body — and silently filter out any finding that fails the check. The first day I added this verification, my false-positive rate roughly halved.

Two related details matter for the analysis prompt. First, do not include examples of risky clauses in the prompt — they bias the model toward finding risks that look like the examples. We tried prompt-based few-shot teaching for two weeks and walked it back; the bias was clear in the metrics. The taxonomy alone, with no examples, gives more honest output. Second, set temperature=0 (or very low) for the analysis call. Risk classification needs determinism, and the modest creativity loss is irrelevant when you're picking from a fixed taxonomy. The Anthropic API defaults are fine for chat but not for structured classification.

A useful enhancement is to ask Claude to score its own confidence on each finding (low/medium/high) and surface low-confidence findings to legal for explicit triage. This sounds like extra work but it concentrates legal's attention on the right cases — high-confidence findings get a quick yes/no, low-confidence findings get a deeper read. The teams I've worked with all converged on this pattern within the first month.

Validating Findings Before Showing Them to Legal

Between analysis and the UI sits a validation layer that's easy to skip and dangerous to skip. Three checks have repeatedly saved me from embarrassing the system in front of legal.

The first is the quote-presence check: every quote field in a finding must be a substring of the clause body. Use a fuzzy substring match (with whitespace normalization) to allow for line-break differences. Findings that fail this check almost always represent hallucination and should be silently dropped before reaching the UI. Log them for prompt-tuning purposes but never show them to counsel.

The second is the category-budget check. If a single clause comes back with more than three risk findings of the same category, something is wrong. Either the clause is genuinely catastrophic (rare) or the model is producing duplicate findings phrased slightly differently. In the latter case, deduplicate by (category, level) and keep the finding with the longest rationale.

The third is the cross-clause consistency check. Run after analyzing the whole contract: if the same risk category appears with level=high in one clause and level=low in another clause with similar wording, flag the inconsistency for human review. This catches the rare case where Claude's evaluation criteria drifted mid-document — typically due to long-context attention degradation in very long contracts.

These three validation steps add maybe 50 lines of code total but eliminate roughly 70% of the false-positive flow that reaches counsel. The first time you watch a senior lawyer work through 30 findings without rolling their eyes, you'll know it was worth the engineering time.

Version Diffing — Match by Clause ID, Not Whole-Document Diff

The single biggest reason legal teams keep using AI review is that they can see "what changed since last time" at a glance. Whole-document text diffs are useless here — clause-level diffs that classify changes as added / removed / modified are an enormous cognitive win.

# diff_engine.py
# Solves: compare old and new versions of the same contract by clause and classify changes.
from dataclasses import dataclass
from difflib import SequenceMatcher
 
@dataclass
class ClauseDiff:
    clause_id: str
    change: str  # "added" | "removed" | "modified" | "unchanged"
    similarity: float
    old_body: str | None = None
    new_body: str | None = None
 
def diff_clauses(old: list[dict], new: list[dict], modify_threshold: float = 0.85) -> list[ClauseDiff]:
    old_map = {c["clause_id"]: c["body"] for c in old}
    new_map = {c["clause_id"]: c["body"] for c in new}
    results: list[ClauseDiff] = []
    for cid, body in new_map.items():
        if cid not in old_map:
            results.append(ClauseDiff(cid, "added", 0.0, None, body))
            continue
        sim = SequenceMatcher(None, old_map[cid], body).ratio()
        if sim >= modify_threshold:
            results.append(ClauseDiff(cid, "unchanged" if sim > 0.99 else "modified", sim, old_map[cid], body))
        else:
            # Very low similarity — treat as a meaningful rewrite
            results.append(ClauseDiff(cid, "modified", sim, old_map[cid], body))
    for cid, body in old_map.items():
        if cid not in new_map:
            results.append(ClauseDiff(cid, "removed", 0.0, body, None))
    return results

The 0.85 threshold for SequenceMatcher is empirical — most real semantic changes register below 0.85. Push it higher and trivial edits start triggering "modified," which exhausts the legal team. In practice, tune the threshold per contract type: 0.92 for NDAs (strict), 0.80 for service agreements (lenient).

A common improvement request is "show us the actual word-level diff for modified clauses." This is straightforward to add with difflib.unified_diff against the bodies, but the UI consideration matters more than the algorithm. Render the diff with old text struck through and new text highlighted in green — that's what legal counsel are accustomed to seeing in track-changes documents in Word. A side-by-side display works less well; counsel scan vertically, not horizontally.

When clause IDs themselves change between versions (renumbering after a section is deleted), pure ID matching produces false "removed" and "added" pairs. To handle this, run a fallback similarity match for each "removed" clause against all "added" clauses; if any pair scores above 0.7, treat them as a renumbered modification rather than a delete-add. This catches roughly 80% of renumbering cases at the cost of a small O(n²) compare. For contracts with hundreds of clauses you may want to gate this with a length-based pre-filter.

Remediation — Generate Concrete Rewrite Suggestions with Citations

The final hill to climb is remediation. "We found a risk" doesn't move the needle in real workflows — "here's how to rewrite it" is what shortens legal review time. Every suggestion must contain three things: the proposed rewrite, why it's safer, and which case law / statute / internal policy backs it up.

# remediation.py
# Solves: take a detected risk and produce a (rewrite, rationale, citations) triple.
from anthropic import Anthropic
from pydantic import BaseModel
 
client = Anthropic()
 
class Remediation(BaseModel):
    proposed_clause: str
    why_safer: str
    references: list[str]
 
PROMPT = """You are an AI assistant supporting in-house counsel. Produce a rewrite that addresses the detected risk in the clause below.
 
[Inputs]
- Original clause: {body}
- Detected risk: {category} ({level})
- Supporting quote: {quote}
- Internal policy summary: We cap liability at 1x contract value and require GDPR-compliant data handling.
 
[Output schema]
{{
  "proposed_clause": "rewritten clause (English, sufficient length)",
  "why_safer": "why this rewrite reduces risk (<= 200 chars)",
  "references": ["UCC §2-719", "Internal Policy v2.3 §4"]
}}
Output JSON only."""
 
def propose_remediation(body: str, category: str, level: str, quote: str) -> Remediation:
    resp = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1500,
        messages=[{
            "role": "user",
            "content": PROMPT.format(body=body, category=category, level=level, quote=quote),
        }],
    )
    raw = resp.content[0].text.strip()
    if raw.startswith("```"):
        raw = raw.split("```")[1].lstrip("json\n").rstrip()
    return Remediation.model_validate_json(raw)

references is mandatory by design. It exists to stop legal counsel from copy-pasting AI rewrites into negotiation drafts without verification. The rule on the team is: any AI suggestion must be reviewed against the cited statute or policy before being used. This isn't just about quality — it's a corporate risk-management call to keep contract approvals in human hands.

The internal-policy summary in the prompt is the single most impactful tuning knob in the whole system. A two-sentence policy ("we cap liability at 1x; we require GDPR-compliant data handling") produces generic remediations. A two-paragraph policy with specific clause patterns the company prefers ("liability cap should be 1x annual fees, capped at $500K, mutual; carve-outs limited to gross negligence and IP infringement") produces remediations that pass legal review with minor edits. Treat the policy text as a first-class artifact — version it, review it quarterly, and run regression tests when it changes.

If your team has a contract template library, even better: include a relevant template snippet in the prompt as a "preferred clause structure" example. Claude is excellent at adapting an existing template to fit the surrounding contract context. This is the place where a small amount of retrieval-augmented generation pays back enormously — fetching the most relevant template by clause category before generating the remediation.

Production Pitfalls You Will Hit, and How to Pre-empt Them

What follows are lessons paid for in production incidents. If you're considering this kind of system, please bake these in from day one.

Pitfall 1: Costs come in at 3× your estimate A 50-page contract × 30 clauses sent through Claude costs roughly $0.70–$1.40 per contract. At 100 contracts/month that's $70–$140. The estimate looks fine. The reality is that the same contract gets re-reviewed three times per legal cycle, and prior versions get re-analyzed for comparisons — and your bill is 3× what you projected. The fix is to cache clause-level analysis keyed on clause_id + SHA256(body). Clauses that haven't changed don't get re-analyzed. This single optimization usually trims 60% off the bill.

A second cost lever is prompt caching. Anthropic's prompt-cache feature lets you mark the long static taxonomy section of your analysis prompt as cacheable, dropping per-request input cost on cached tokens by roughly 90%. The savings compound when you analyze 30 clauses per contract — each clause re-uses the same taxonomy. Wire prompt caching in from day one rather than retrofitting it; the integration is a single header but the architectural decision (where to put the cache boundary in your prompt) is harder to change later.

Pitfall 2: Audit logs are missing when the auditor shows up "Which model evaluated this risk on which date?" needs to be answerable months later. ISO 27001 / SOC 2 audits will ask. At minimum, persist these fields in an audit_log table: request_id, model (e.g., claude-sonnet-4-6), prompt_hash, response_hash, tokens_in, tokens_out, unit_cost, created_at, reviewed_by. The Claude response always carries an id — use it as request_id. If you skip this, the day an auditor asks you to re-run an old review you'll get different output and the explanation falls apart.

Storing the full prompt and response (not just hashes) is worth the storage cost. Compressed text is cheap; legal-discovery requests are expensive. The first time legal asks "show me everything the AI said about contract X in March," you'll be glad you have full payloads, not just hashes. A compressed JSON column in PostgreSQL handles this fine for years of contracts at modest cost. If your storage cost projections still spook compliance, archive payloads older than 12 months to S3 Glacier — the retrieval latency is fine for audit cases.

Pitfall 3: Legal stops trusting the AI Before pouring effort into accuracy, redesign the UI. The screen should not be "a list of Claude's findings" — it should be "a screen where counsel records their final judgment." For each AI finding, present accept / reject / hold buttons, and require a structured reason for rejection. Without this human-in-the-loop framing, no amount of model improvement will keep legal from feeling pushed around by the AI. This UI change alone tripled continued usage in my deployments.

The structured rejection reasons also become your most valuable feedback signal for prompt iteration. After three months, the most common rejection reasons tell you exactly which categories of false positive to suppress in the next prompt revision. One of the teams I worked with discovered that "indemnification" findings on standard mutual-indemnity clauses were being rejected 80% of the time — they tightened the prompt to ignore symmetric mutual indemnification, and the system's signal-to-noise ratio jumped overnight. Without structured rejection capture, that learning cycle never happens.

Pitfall 4: Model upgrades break review consistency The day you migrate from claude-sonnet-4-6 to a future top model, you'll see subtle drift versus historical reviews. Legal will say, "the same contract gives a different answer — I can't trust this." The fix is to version your prompt + model combination as a "review template version" and keep historical contracts reproducible against the original template. When migrating, run both models in parallel and migrate contract-by-contract starting with the lowest-divergence cases.

Pitfall 5: Multi-language contracts produce inconsistent findings Cross-border contracts often have parallel English and Japanese (or other) text. Sending both languages to Claude in the same call leads to risk findings that mix and match across the languages — sometimes quoting English, sometimes Japanese, sometimes hybrid sentences that exist in neither version. The fix is to detect the document language up front, choose the canonical version (usually the one specified in the governing-law clause), and analyze only that. Mark the other versions as "translation copies" and out-of-scope for risk analysis.

Pitfall 6: The system silently degrades when a clause exceeds the segmentation token limit Very large clauses — typically heavily-amended liability sections that have grown over years — can exceed the max_tokens budget for a single Claude segmentation pass. When that happens, the model truncates the body field rather than failing loudly. Always validate that the sum of len(c.body) across all returned clauses is within 95% of the input character count. If it falls below that, raise a clear error and fall back to multi-pass segmentation. Silent truncation is the failure mode that creeps into production unnoticed and embarrasses you in front of legal three months later.

Operational Considerations Beyond the Code

Two things tend to surprise teams once the system is live, and both are worth designing for from day one.

First, the system inevitably becomes a load-balancer for legal work. Once counsel see the AI handling boilerplate clauses confidently, they push more borderline contracts through it — vendor agreements that they would previously have skimmed manually now get a full AI pass. This is mostly a win, but it can quadruple your contract volume in the first quarter post-launch. Plan capacity (and budget) for that.

Second, the audit log becomes legal's negotiation memory. Counsel start querying it for "what did we accept on liability caps in vendor contracts last year?" — a question that previously required hours of manual review. The audit log table thus deserves indexing on (category, level, decision) from day one, even if you don't immediately need those queries. Retroactive indexing on a year of data is a maintenance window you'll want to avoid.

A subtler point: the system changes the legal-engineering working relationship. Engineers gain a much sharper picture of which clauses legal cares about and why; legal gains a faster turnaround on standard contracts and more capacity for genuinely novel ones. Treat the system as a collaboration platform between the two functions, not as a one-way automation. The teams that internalized this got the most value out of the deployment; the teams that treated it as "engineering ships, legal consumes" stalled within six months.

A Concrete First Step

Once you're done reading this, pick five NDAs your team currently handles and run them through just the first two steps in this guide — clause segmentation followed by risk analysis. Hold off on remediation and version diffing until those two steps have earned a "this is actually useful" verdict from your legal team. Building everything at once collapses into a requirements-gathering swamp; staged delivery is the only way I've seen this succeed.

A practical tip on selecting those first five NDAs: pick contracts the team has already reviewed manually within the last quarter, so you have a "ground truth" baseline to compare against. Don't pick contracts that no one has read recently — you'll have nothing to validate against, and the project will drift into "the AI says this; I guess that's right." The five-contract baseline takes about a day of legal time to compile and pays dividends for the rest of the project.

If you want to dig further into the Claude API patterns this guide builds on, three related articles will reinforce the foundations: the Claude API Tool Use Complete Guide for stricter structured outputs, the Claude API Cost Optimization Guide for managing spend at production scale, and Mastering Claude's 200K Context Window in Production for handling the long documents this system depends on.