The extraction job finishes clean. Every contract in the batch produces valid JSON, every field is populated, the schema validator passes, and the results load into the obligation tracker without a single error. Three weeks later someone in legal asks why the tracker says the renewal notice window is 30 days when the contract says 90. That is the moment you learn the real problem with contract data extraction: the failure mode is not malformed output. It is well-formed output that is wrong.<\/p>\n\n\n\n
This post is a practical guide to how I’d extract contract data with Amazon Bedrock: the clauses, parties, dates, and obligations that feed contract lifecycle tools, obligation trackers, and compliance dashboards. It covers the two build paths Bedrock gives you, how to design the extraction schema, the three failure families that produce confident wrong answers, and the validation layer that catches them before they reach a system someone trusts.<\/p>\n\n\n\n
Bedrock offers two genuinely different routes to the same destination, and picking the wrong one costs you either flexibility or months of pipeline plumbing you didn’t need to build.<\/p>\n\n\n\n
You send the contract to a foundation model, typically Anthropic Claude, through the Converse or InvokeModel API, with a prompt and a schema describing the fields you want back. Converse accepts PDF documents as a content block, so contract bytes go straight from S3 without a separate OCR step. One detail that catches people: full visual understanding of a PDF through Converse with Claude requires citations to be enabled. Without them the API falls back to plain text extraction, and anything living in a table or a scanned signature page silently disappears from the model’s view.<\/p>\n\n\n\n
The piece that changed this path from fragile to dependable is structured outputs. Instead of asking the model nicely for JSON and writing defensive parsing code for the day it prepends an apology, you attach a JSON Schema to the request and Bedrock enforces it during token generation through constrained decoding. The response cannot fail to parse. One mechanic worth knowing: the first request with a new schema triggers a grammar compilation step, and compiled grammars are cached for a limited time, so schema churn has a latency cost.<\/p>\n\n\n\n
Bedrock Data Automation (BDA) is the managed intelligent document processing service. You define a blueprint, which is a list of fields with types and natural language instructions for how to find and normalize each one, attach it to a project, and invoke the async processing API against files in S3. BDA returns two things a raw model call does not give you out of the box: a confidence score per field and visual grounding, meaning bounding boxes pointing back to where on the page each value came from. A project can hold multiple document blueprints, so a mixed intake of NDAs, master service agreements, and amendments routes each document to the right extraction logic automatically.<\/p>\n\n\n\n
My honest read on the choice: BDA wins when you want the boring parts managed and you need per-field confidence and grounding for a human review loop, which for contracts you almost always do. The direct model path wins when you need reasoning the blueprint format can’t express, like interpreting a clause against the definitions section. Plenty of real pipelines use both: BDA for the structured pass, a direct Claude call for the clauses that need interpretation. Amazon Textract still earns its place for high-volume standardized forms, but contracts are exactly the variable, long-tail documents layout-based extraction was never great at.<\/p>\n\n\n\n
The schema is not a formality. With structured outputs, the field names, descriptions, and ordering you write become context the model generates against, so the schema is effectively part of the prompt. A vague schema produces structurally valid garbage: JSON that parses perfectly and means nothing.<\/p>\n\n\n\n
Three design rules that pay for themselves. First, one concept per field: “renewal terms” as a single string is unusable downstream; split it into whether renewal exists, whether it is automatic, the duration, and the notice period to prevent it. Second, write field descriptions like instructions to a junior reviewer, including what the field is not. Third, make every field nullable and tell the model to return null when the contract is silent. A model forced to fill a required field will fill it with something.<\/p>\n\n\n\n
Here is the shape I’d start with for a general commercial agreement, trimmed to the core:<\/p>\n\n\n\n
{\n \"type\": \"object\",\n \"properties\": {\n \"parties\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"object\",\n \"properties\": {\n \"legal_name\": { \"type\": [\"string\", \"null\"],\n \"description\": \"Full registered entity name from the preamble or signature block, not the defined shorthand\" },\n \"defined_term\": { \"type\": [\"string\", \"null\"],\n \"description\": \"The shorthand assigned in the preamble, e.g. Supplier, Client\" },\n \"role\": { \"type\": [\"string\", \"null\"] }\n }\n }\n },\n \"effective_date\": { \"type\": [\"string\", \"null\"],\n \"description\": \"Date the agreement takes effect. Null if only a signature date exists.\" },\n \"governing_law\": { \"type\": [\"string\", \"null\"] },\n \"obligations\": {\n \"type\": \"array\",\n \"items\": {\n \"type\": \"object\",\n \"properties\": {\n \"obligor\": { \"type\": [\"string\", \"null\"] },\n \"description\": { \"type\": [\"string\", \"null\"] },\n \"deadline_text\": { \"type\": [\"string\", \"null\"],\n \"description\": \"The deadline exactly as written, e.g. within 30 days of the Effective Date\" },\n \"source_clause\": { \"type\": [\"string\", \"null\"],\n \"description\": \"Section number where this obligation appears\" }\n }\n }\n }\n }\n}<\/code><\/pre>\n\n\n\nNotice deadline_text<\/code> keeps the deadline as written instead of asking the model to compute a calendar date. That is deliberate, and the reason is the second failure family below.<\/p>\n\n\n\nFailure family one: parties that aren’t who they say they are<\/h2>\n\n\n\n
Contracts name their parties once, in the preamble, then never again. From that point on everything refers to “the Supplier” or “the Receiving Party.” A naive extraction returns the defined term as the party name, which is useless for matching against a vendor master or a CRM. Worse, the signature block sometimes names a different legal entity than the preamble, usually an affiliate signing on behalf of a subsidiary, and the model will happily pick whichever it saw last.<\/p>\n\n\n\n
The fix is structural, not clever prompting. Extract the legal name and the defined term as separate fields, as in the schema above, with instructions to take legal names from the preamble and cross-check the signature block. Then validate outside the model: if the two entities differ, flag the document for review rather than picking one. That mismatch is occasionally a genuine drafting error in the contract itself, which makes it exactly the kind of thing you want surfaced, not smoothed over.<\/p>\n\n\n\n
Failure family two: dates that mean different things<\/h2>\n\n\n\n
A contract carries several dates that look interchangeable and are not: execution, effective, commencement, expiry, and the deadlines derived from notice periods. The extraction failure that costs money is almost never a misread date string. It is a correctly read date assigned to the wrong concept, or a relative deadline flattened into a wrong absolute one.<\/p>\n\n\n\n
Relative dates are the invisible one. “Either party may terminate by written notice no later than ninety days before the end of the then-current term” contains no date at all. If your schema demands a date type, the model computes one, and its arithmetic rests on assumptions about the term start that may be wrong, especially when an amendment has reset the term. That computed date looks exactly as trustworthy in your tracker as a real one. This is why I extract deadline language verbatim and compute calendar dates in code, where the arithmetic is testable and the inputs are auditable.<\/p>\n\n\n\n
Cheap validation catches most of the rest. The effective date must not fall after the expiry. A notice period must be a plausible number of days. If the agreement auto-renews, a renewal duration should exist. Fields that fail these checks get flagged. None of this needs a model; it is twenty lines of code standing between extraction and the systems people trust.<\/p>\n\n\n\n
Failure family three: obligations, cross-references, and the amendment problem<\/h2>\n\n\n\n
Obligations are the hardest target because they are relational. “The Supplier shall deliver the reports described in Schedule 3 within the period set out in Section 4.2, except as provided in Section 9” is one obligation spread across three locations. Chunk the contract carelessly and the model sees the reference with no Section 4.2 in sight. It will either drop the deadline or invent a plausible one, and the second outcome is far worse because nothing downstream looks broken.<\/p>\n\n\n\n
Contracts resist chunking more than almost any other document type, because defined terms and cross-references make every section depend on distant ones. The practical answers, in order of preference:<\/p>\n\n\n\n
\n- Don’t chunk. Modern model context windows fit most commercial agreements whole, and whole-document extraction is the single biggest accuracy win available. Reach for chunking only when a document genuinely doesn’t fit.<\/li>\n\n\n\n
- If you must split, prepend the definitions section and the table of contents to every chunk, and split on section boundaries rather than fixed token counts so no clause straddles a cut.<\/li>\n\n\n\n
- Capture the source clause reference for every obligation, as in the schema above, so a reviewer can jump straight to the language instead of re-reading the contract.<\/li>\n<\/ol>\n\n\n\n
Then there are amendments. An amendment is a short document that quietly rewrites the base agreement, and if you extract each file independently your dataset will assert the original terms with full confidence long after they stopped being true. Treat the contract family, not the file, as the unit of extraction: process the base agreement, process each amendment, and resolve them in order so later documents override earlier ones. BDA’s multi-blueprint routing helps here, since amendments have a recognizably different shape and can carry their own blueprint focused on what changed.<\/p>\n\n\n\n
The validation layer that makes it trustworthy<\/h2>\n\n\n\n
Schema compliance tells you the output is well-formed. It says nothing about whether it is true. The trust comes from three checks layered after extraction.<\/p>\n\n\n\n
\n- Cross-field consistency.<\/strong> Dates in order, notice periods plausible, every obligation carrying an obligor that matches an extracted party. Pure code, no model.<\/li>\n\n\n\n
- Grounding.<\/strong> Every extracted value should point back to a location in the document. BDA gives you this natively through bounding boxes; on the direct model path, requiring a source clause reference per field is the lightweight version. A value that cannot be traced to the page is a value you cannot audit.<\/li>\n\n\n\n
- Confidence-based routing.<\/strong> Use BDA’s per-field confidence scores to route low-confidence extractions to human review and let high-confidence ones flow through. The goal is not eliminating review; it is spending reviewer minutes only where the model is unsure. Party names and governing law typically extract very reliably, while obligations from unusual templates are where automation honestly ends and review begins.<\/li>\n<\/ul>\n\n\n\n
Operationally this looks like S3 event notifications triggering a Step Functions workflow: extract, validate, then branch to auto-accept or a review queue. Instrument it from day one. Track the auto-accept rate, per-field confidence distributions, and validation failure counts; a slow drift in confidence is usually the first sign a new contract template has entered the intake. I ship these to Grafana Cloud with the rest of the pipeline metrics, and since direct model calls bill by tokens while BDA bills per unit of content processed, a cost dashboard in something like Vantage or CloudZero shows quickly whether whole-document extraction is worth its token count for your mix. It usually is.<\/p>\n\n\n\n
Troubleshooting<\/h2>\n\n\n\n
Fields come back null for content that is clearly in the document.<\/strong> On the Converse path with PDFs, check whether you are getting text-only extraction; content in tables, stamps, or scanned pages needs the visual analysis mode. For scans, verify image quality before blaming the model.<\/p>\n\n\n\nThe same contract extracts differently on reruns.<\/strong> Set temperature to zero for extraction work, then look for instructions the model can resolve more than one way. Ambiguity in a schema description is the usual culprit.<\/p>\n\n\n\nFirst requests with a new schema are slow.<\/strong> That is grammar compilation for structured outputs. Stabilize your schemas and warm them before batch runs rather than generating schemas dynamically per request.<\/p>\n\n\n\nBDA accuracy is mediocre on your templates.<\/strong> Blueprint instructions are tunable, and BDA can refine them automatically from a small set of example documents with known correct values. Feed it your hardest real examples, not your cleanest ones.<\/p>\n\n\n\nCommon mistakes<\/h2>\n\n\n\n\n- Treating schema-valid JSON as verified data. Structure and truth are separate properties, and the second one needs its own checks.<\/li>\n\n\n\n
- Extracting the defined term as the party name and matching it against vendor records.<\/li>\n\n\n\n
- Letting the model compute calendar dates from relative deadline language instead of extracting the language and computing in code.<\/li>\n\n\n\n
- Chunking by token count through a document whose clauses reference each other across fifty pages.<\/li>\n\n\n\n
- Processing amendments as standalone documents and silently keeping stale base-agreement terms.<\/li>\n\n\n\n
- Making every schema field required, which converts “the contract is silent” into a fabricated answer.<\/li>\n<\/ul>\n\n\n\n
Best practices<\/h2>\n\n\n\n\n- Extract whole documents whenever the context window allows. Every chunking strategy is a workaround, not a feature.<\/li>\n\n\n\n
- Keep a small labeled evaluation set of your own contracts and score every prompt or blueprint change against it before shipping.<\/li>\n\n\n\n
- Require a source reference for every extracted value, whether that is a BDA bounding box or a clause number from the model.<\/li>\n\n\n\n
- Route on confidence and validation results, and measure your auto-accept rate as a first-class metric.<\/li>\n\n\n\n
- Version your schemas and store the schema version alongside every extraction, so you can tell which records predate a fix.<\/li>\n\n\n\n
- Keep humans in the loop for high-stakes fields. The realistic goal is automating the bulk and focusing legal review, not replacing it.<\/li>\n<\/ul>\n\n\n\n
FAQ<\/h2>\n\n\n\nShould I use Bedrock Data Automation or call Claude directly for contract extraction?<\/h3>\n\n\n\n
BDA if you want managed parsing, per-field confidence scores, and visual grounding for a review workflow. Direct model calls if you need interpretive reasoning over clauses or conversational access to the document. Many production pipelines combine both.<\/p>\n\n\n\n
Do I still need Amazon Textract?<\/h3>\n\n\n\n
Usually not as the primary extractor for contracts, since layout-based extraction struggles with variable legal drafting. It remains a good fit for high-volume standardized forms, and some pipelines route documents between Textract and generative extraction by type.<\/p>\n\n\n\n
How accurate is contract data extraction in practice?<\/h3>\n\n\n\n
It varies sharply by field type. Parties, governing law, and explicit dates extract reliably. Obligations, renewal mechanics, and anything expressed through cross-references are meaningfully harder, which is why confidence routing and human review exist. Distrust any vendor quoting one accuracy number for “contracts.”<\/p>\n\n\n\n
How do I extract obligations specifically, not just metadata?<\/h3>\n\n\n\n
Model each obligation as its own object with obligor, description, deadline language, and source clause. Extract against the whole document so cross-references resolve, and validate that every obligor matches an extracted party.<\/p>\n\n\n\n
Can Bedrock handle scanned contracts?<\/h3>\n\n\n\n
Yes. BDA processes scanned documents as part of its parsing stage, and Claude’s visual document understanding reads scanned pages when invoked with visual analysis. Scan quality still matters; poor scans degrade every approach.<\/p>\n\n\n\n
Is it safe to put contracts through Bedrock?<\/h3>\n\n\n\n
Bedrock runs within your AWS account boundary, and AWS states that customer content is not used to train the underlying models. For sensitive agreements the usual controls apply: VPC endpoints for private connectivity, KMS encryption on the buckets, and IAM scoped to the pipeline roles. Confirm the specifics against your own compliance requirements.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
If you remember one thing, make it this: when you extract contract data with Amazon Bedrock, valid output is the starting line, not the finish. Structured outputs and BDA blueprints have genuinely solved the formatting problem, which means the remaining risk is concentrated in meaning: the wrong entity, the wrong date concept, the obligation whose deadline lives two sections away. Design the schema around those failures, validate outside the model, ground every value to the page, and route on confidence. That is the difference between a demo and a pipeline a legal team will actually trust.<\/p>\n\n\n\n
\n\n\n\nNeed help building a contract extraction pipeline on AWS?<\/h2>\n\n\n\n
I design and build document intelligence pipelines on AWS as a freelance DevOps engineer. If you’re extracting data from contracts or other legal documents, here’s what I can help with:<\/p>\n\n\n\n
\n- Designing extraction schemas and BDA blueprints for your actual contract types, including amendments and multi-document families<\/li>\n\n\n\n
- Building the full serverless pipeline: S3 intake, Step Functions orchestration, extraction, validation, and review routing<\/li>\n\n\n\n
- Adding the validation and grounding layer that catches confident wrong answers before they reach your CLM or tracker<\/li>\n\n\n\n
- Setting up evaluation sets and accuracy measurement so prompt and blueprint changes are tested, not guessed<\/li>\n\n\n\n
- Locking down the security side: VPC endpoints, KMS encryption, and IAM scoping for sensitive documents<\/li>\n\n\n\n
- Cost tuning across model choice, whole-document versus chunked extraction, and BDA versus direct model calls<\/li>\n<\/ul>\n\n\n\n
Send me a sample contract (redacted is fine), your target field list, or the output of a pipeline that isn’t behaving, and I’ll tell you what I’d do with it.<\/p>\n\n\n\n