Document Comparison Pipeline

Comparing two versions of a contract, policy, or regulatory filing has two halves. Finding the literal differences is a deterministic problem that ordinary diff tooling solves perfectly. Explaining what those differences mean — which changes are substantive, which are cosmetic, and what a reviewer should look at first — is a judgment problem, and that is where Claude earns its place. A good pipeline keeps the two halves separate.

The pipeline in five stages

1. Normalize. Convert both versions to a common text representation. Claude accepts PDFs directly as document content blocks — each page is converted to an image with its extracted text provided alongside, at roughly 1,500–3,000 text tokens per page — but for comparison work, extracting text yourself first gives you something you can diff deterministically. Note that .docx and .xlsx files are not supported in document blocks; convert those to plain text or PDF first.

2. Diff in code. Run a standard textual diff between the two normalized versions. This step costs nothing, never hallucinates, and gives you a precise change list. Do not ask the model to "find all differences" between two long documents — that is asking it to do a mechanical job unreliably.

3. Classify each change with Claude. Send each diff hunk, with surrounding context from both versions, and ask for a classification (substantive / clarifying / cosmetic), a plain-English summary, and the affected obligations. Long-context prompting guidance applies: put the document material at the top of the prompt and the question at the end, wrapped in <document> tags — queries at the end can improve response quality by up to 30%.

4. Ground the analysis with citations. Enable "citations": {"enabled": true} on the document blocks so every claim in the summary points back to a location in the source. Plain-text documents return character-offset citations; PDFs return page-location citations. Cited text does not count toward output tokens, which makes citation-heavy delta reports cheaper than prompting the model to quote passages manually.

5. Assemble the delta report. Your application code — not the model — orders the classified changes, groups them by section, and renders the final report. Include a human review step for anything classified as substantive; a change-detection pipeline for contracts should recommend, not decide.

Cost and scale controls

Version-to-version comparison naturally reuses one side of the input: the "old" version is identical across every hunk you classify. Put the shared document behind a prompt-cache breakpoint (cache_control: {"type": "ephemeral"}) so repeated requests read it at one-tenth the input price instead of paying full price each time. If you compare documents in nightly jobs rather than interactively, the Message Batches API halves the token price — but note where it runs (next section). The free token-counting endpoint is useful for estimating cost before you submit: it is stateless, so count each version separately and subtract to size the work.

Platform availability

Two Bedrock-specific caveats. PDFs must be sent base64-encoded (no URL or file references), and on the Converse API full visual PDF understanding requires citations enabled — without them it falls back to text-only extraction. And while Anthropic's Message Batches API is absent on Bedrock and Vertex AI, both clouds offer their own cloud-native batch inference for Claude (S3-based on Bedrock, BigQuery/GCS-based on Vertex at 50% batch pricing), so overnight comparison jobs remain possible there through a different mechanism.

Where to go next

For the citation mechanics in depth, see the citations article; for handling whole-document summarization rather than deltas, see the summarization pipeline. The feature matrix shows what runs where.

Sources

• PDF support
• Citations
• Prompting best practices
• Token counting
• Prompt caching