Contract review is a natural fit for Claude: the input is long, the questions are repetitive ("what is the liability cap? does indemnification cover IP claims?"), and the output must point back to exact language. The workflow below is first-pass triage — it accelerates attorneys, it does not replace them, and nothing in it should be treated as legal advice.
Stage 1: Ingest the contract as a PDF
Send the contract as a PDF document block. PDF support is available on the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud, and Microsoft Foundry, with a 32 MB request cap and up to 600 pages per request (100 pages when the context window in play is under 1M tokens). Each page is processed as both extracted text and an image, so expect roughly 1,500–3,000 text tokens per page plus vision tokens. On Bedrock and Google Cloud you must send the PDF as base64 — URL and Files API references are not supported there.
Stage 2: Extract clauses with citations turned on
The single most important design choice: enable citations on the document ("citations": {"enabled": true}). For PDFs, Claude returns page_location citations with the exact cited_text, so every extracted clause carries a pointer a human can check in seconds. Cited text does not count toward output tokens. One hard limitation to plan around: citing images inside PDFs is not supported, so a scanned contract with no extractable text layer is not citable — run OCR upstream and treat un-OCRable documents as automatic human-review cases.
Stage 3: Flag risk against your playbook — in a second pass
You will want machine-readable risk output (clause type, position, severity), which suggests structured outputs. But the API returns a 400 error if you combine citations with output_config.format in the same request. The clean architecture is therefore two passes:
| Pass | Input | Feature used | Output |
|---|---|---|---|
| 1. Extract | Contract PDF | Citations | Clause inventory with quoted text and page numbers |
| 2. Assess | Pass-1 clauses + your playbook | Structured outputs | JSON risk flags per clause |
The "playbook" is your negotiation standard: preferred, acceptable, and walk-away positions per clause type. Put it in the system prompt behind a prompt-cache breakpoint — it is identical for every contract, so after the first request you pay roughly one-tenth of the input price to reuse it (cache reads are billed at 0.1x the base input rate). Adaptive thinking (thinking: {"type": "adaptive"}) is worth enabling for the assessment pass, where weighing a non-standard indemnity clause genuinely benefits from deliberation.
Stage 4: Attorney handoff protocol
The handoff is process design, not an API feature — treat what follows as recommended practice. Route every contract to a queue where an attorney sees three panes: the original PDF, the clause inventory with clickable page citations, and the risk flags with the playbook position each one was compared against. Three rules keep the system honest:
Everything is reviewable, some things are mandatory. Define clause types (limitation of liability, indemnification, termination, data protection) whose flags always require attorney sign-off regardless of the model's severity rating.
No silent negatives. If an expected clause type is absent from the extraction, surface "not found" explicitly — an absent liability cap is itself a finding.
Log the disagreements. When attorneys override a flag, record it. That log is your evaluation set for prompt and playbook improvements, and your evidence base when someone asks whether the system is trustworthy.
Contracts are sensitive data: running this on a 3P platform inherits your cloud provider's compliance posture — confirm specifics (retention, residency, sector rules) with your provider before processing client documents.
Where to go next
See PDF support details, how citations work, and Claude for legal teams for the broader use-case picture.