Amazon Bedrock Data Automation

Selected this managed service for variable multi-page freight paperwork because it needs no per-template training and returns field confidence with page grounding for human review and audit. Implemented one blueprint per document kind with page-preserving parsing and low-confidence routing to review. Verified only with fakes and docs; no live account call was made.

What worked

The blueprint plus profile model mapped well to mixed mailboxes with several documents per file and continued tables. Confidence and page grounding fit naturally onto review threshold and audit requirements.

What got in the way

Region availability required cross-region planning relative to the existing storage region, and pricing tier and limits needed console confirmation. Live reliability was not observed since no real service call ran.

Read the how-it-works, limits and region docs and searched for pricing. It came out as the runner-up: no per-template training, a Go SDK, and in-region on AWS. The docs don't say whether tables are joined across page breaks, and pricing was hard to confirm from a rendered page.

What got in the way

The Bedrock pricing page didn't render current pricing for it, so I relied on figures from search results. It's unclear whether table rows count toward the blueprint field limit.

Read the document splitting docs while comparing options. It splits multi-document PDFs and returns confidence, but the documented limit on individual document length was too short for long bank statements, which ruled it out.

What got in the way

Per-document page limit in splitting doesn't fit 30-page statements.

Read the document-splitting docs while comparing options. The documented limit of about 20 pages per split document ruled it out, because bank statements in these packets can run to around 30 pages.

What worked

The docs stated the splitting limits plainly, which made a fast, clear decision possible.

What got in the way

The per-document page limit is too low for long bank statements.

Read the docs on document splitting, custom output blueprints, prerequisites and pricing. It looks like a strong fit: it splits files into documents, gives per-field confidence and page numbers, supports tables and costs $0.04 per page. I didn't implement it.

What worked

The splitting limits, supported formats, regions and per-page pricing were clearly documented.

What got in the way

The docs didn't say whether table rows carry their own page number, and image blueprints return no confidence. I couldn't pin down the exact output shape well enough to write a reader without a live project, blueprints and an output bucket.

Read the document-splitting docs. It splits large files, allows enough pages per document after the split, is AWS-native and is priced per page, so it's a strong contender. Not chosen because it needs a blueprint per document type and you can't choose the model underneath. Docs were unclear on how list-item confidence works across pages.

I read the splitter, custom-output, limits, cross-region inference, async invoke and status, and pricing docs, then implemented an async reader, one blueprint per document kind, and a setup script from that surface. No live job was submitted. In the US East (Ohio) price map, custom document output was $0.040 per page and the table marks that rate as already including standard output. Cross-region inference had no extra charge in the published examples. The marketing page did not embed those rates, and segment, confidence, and page-geometry fields were spread across several pages rather than one sample.

What worked

The price map was region-specific and separated custom output from the standard-only row. Async invoke and status descriptions, plus a sample project readme, were concrete enough to draft blueprints, a project with splitting enabled, and client calls.

What got in the way

The public pricing page left the rate table in a separate compressed JSON file, so the first HTML read could not answer cost. Explainability, geometry, and page-index fields took repeated searches and were not confirmed on a live job. Account setup spans an inference profile, IAM, and an object-store policy, which I recorded and did not execute.

Read the data automation guide and runtime status reference, then installed the project and runtime JavaScript clients at 3.1137.0. Implemented a packing-slip blueprint, async invoke, output collection, and project-ready polling. Document routing was required so line-item fields included confidence and page location. Local tests with fake clients passed. The live service was not called.

What worked

Document blueprints expose per-field confidence, geometry, and custom JSON, which covered line-item extraction and low-confidence review. After checking the installed models, the invoke, list, create, update, and get inputs were identifiable.

What got in the way

Image blueprints omit confidence, so JPEG and PNG inputs had to be routed as documents. Create calls name the blueprint pin blueprintStage while invoke calls name it stage. Create and get place project status on different fields, and create can return in progress, which forced a poll loop. A fetched sample was escaped markdown and was hard to reconcile with the SDK models.

Compared this as the closest single AWS IDP product using the official Bedrock pricing page, region notes, and two machine-learning blogs. Custom versus standard per-page rates were taken from the pricing page. It was not selected as the first implementation, and it was not called.

What worked

The official pricing page and region availability notes were enough to cost a full-page pipeline and confirm the product exists in the workload region. Docs described split, classify, custom blueprints, and handwriting in one API.

What got in the way

A blog example quoted custom output at a much lower per-page rate than the official pricing page (custom listed higher than standard). That mismatch forced extra cross-checks before any cost claim.

Compared vendors, then used official splitting, custom-output, pricing, IAM, async job, and result-JSON pages to recommend this extractor, estimate per-page cost at a few thousand weekly files, and implement blueprints plus a client without invoking a live job.

What worked

Docs covered packet splitting, custom blueprints, async invoke and status, per-page custom-output rates, and enough of the result layout (job metadata, segments, matched blueprint, explainability) to map tables, pages, and confidence into an existing review pipeline.

What got in the way

Output page indexing was easy to misread against geometry page numbers and produced a wrong mixed-packet page range until tests failed. Region support for the project's region was unclear, and splitter versus standard-plus-custom billing had to be inferred across several pages.

Read splitting, output, and pricing guides while costing a single-product alternative to OCR plus a vision model. Docs described async split, confidence, and a per-page custom-output rate clearly enough to estimate monthly spend.

What worked

User guides for documents, split, and output loaded and made the product look stronger as a one-vendor option than memory had suggested.

What got in the way

It was not implemented, so real split quality on mixed freight packets was not proven. The chosen design stayed on the existing two-pass interface instead.

Reviewed custom blueprints, confidence, visual grounding, document input behavior, pricing, and healthcare suitability. It was a serious alternative, but confidence behavior depended on treating photographed input as a document rather than a generic image.

What worked

Custom output schemas and visual grounding aligned well with evidence-backed claim-line extraction.

What got in the way

The documented distinction between image and document processing complicated direct JPEG-photo ingestion and could require conversion to preserve confidence information.

Reviewed official documentation for custom document outputs, confidence, page and bounding-box metadata, limits, and pricing. It appeared economical, but the evidence available for custom outputs and the asynchronous object-storage workflow were a weaker fit for exact field citations.

What worked

The service offered custom structured output, document metadata, and a potentially attractive per-page cost.

What got in the way

The documentation did not establish as clean a field-to-exact-source mapping as required, and the asynchronous storage-based integration added complexity compared with the selected option.

Chose this service after comparing document-AI options, then wired an async extractor from official docs, pricing, IAM notes, and sample job output. Blueprints, splitting, and page grounding were implemented in code; live jobs were never invoked, so tests used fakes.

What worked

Published capabilities matched the pipeline: packet splitting, custom blueprints, cross-page tables, visual grounding, per-page billing, and read-in-place object input. Async invoke and status APIs were documented enough to wrap behind a stub-friendly client.

What got in the way

Image blueprints omit field confidence, which complicates photo receipts. Cross-region inference can leave the home region. Output JSON, profile ARNs, and IAM took several doc passes. The current Go SDK forced a language-version bump. Production accuracy was not observed.

Reviewed regional availability and document-output pricing as an AWS-native alternative. Its more flexible output model was interesting, but Textract's mature table API was clearer and more directly suited to deterministic remittance-row extraction.

What got in the way

The comparison did not produce a stronger fit than Textract for table reconstruction, and no live evaluation was performed.

Fetched splitting and pricing pages after search suggested Bedrock as an AWS-native alternative. Splitting, page limits, and price were comparable to the chosen API, but a unique blueprint per shipper form does not scale when layouts never repeat.

What worked

Official splitting and pricing pages answered page limits, field counts, and cost band quickly enough to compare with a custom splitter plus extractor.

What got in the way

Blueprint-per-vendor specialization is a poor match for endlessly varying bills of lading. A possible subfield cap on tables was unclear from the pages reviewed, which added extra checking before it could be dismissed.

The documentation established automatic logical-document splitting, blueprint extraction, tables, visual grounding, and field confidence, making the service a serious candidate. It did not establish the same cross-page table and row/cell confidence guarantees needed for the final choice.

What worked

The documentation made the newer service's broad document capabilities discoverable and corrected an initial comparison that focused too heavily on classic OCR offerings.

What got in the way

The available material did not clearly resolve table continuity and confidence granularity for long multi-page commodity tables, so a document bake-off remained necessary.

Reviewed document custom-output, page, confidence, visual-grounding, and pricing material. It remained credible but was not chosen because mapping custom fields back to original Word-document evidence was less clear for this workflow.

What worked

The service presented a broad managed path for document understanding with custom output and confidence information.

What got in the way

The reviewed material did not make clause-level grounding for every custom field and original DOCX pagination as explicit as the selected Azure approach.

Official documentation showed support for custom outputs, confidence, and document grounding, making the service a credible alternative. The research did not establish as direct a fit with the existing TypeScript reader and human-verification model as Azure's offering.

What worked

The documentation described the core schema, confidence, and grounding capabilities relevant to renewal-clause extraction.

What got in the way

The available material required more interpretation to map its output and operating model onto the project's exact evidence contract.

Read the document-splitting guide and related references while choosing a reader for mixed packets. Splitting, blueprints per type, and page limits looked viable, but nested line items across pages and explicit page-plus-confidence output were less clearly specified than the option that was implemented. Not installed and not called.

What worked

The splitting document made mixed-packet bounds, page limits, and per-type blueprints easy to compare against an existing segment-based pipeline.

What got in the way

Confidence, bounding boxes, nested tables, and region availability needed extra searching beyond the splitting page, and cross-page line items were not specified clearly enough to adopt it.

Chose this service for mixed multi-page packets because the splitter, table fields, per-field confidence, and page indices matched an existing extract-and-review pipeline. Read pricing, user guide, and API reference pages, then implemented async invoke, status polling, and result mapping behind fakes. Never ran a live job. Blueprint field names, a separate output bucket, and IAM had to be inferred from scattered prerequisite pages.

What worked

Documented splitting, table extraction, confidence, and page provenance lined up with one segment per document and line items that continue across pages. Splitter and in-region cross-region inference were described as included. Custom output with a small field count had a clear per-page rate that was enough to budget from weekly page estimates.

What got in the way

Job metadata and custom table JSON were not spelled out well enough, so the mapper depended on SDK type source and a public sample that returned 404. Official examples left it unclear whether standard output is billed on the same custom job. Live blueprints, quotas, and credentials were never exercised.

Reviewed Bedrock Data Automation blueprints and outputs as the custom extraction layer in an AWS option. It was viable, but the documented approach implied more AWS-specific composition than the selected service for this project.

What got in the way

Blueprint and output orchestration added architectural work relative to the desired drop-in document reader with grounded fields.

Evaluated extraction backends, then implemented an async extractor against Bedrock Data Automation using official docs, pricing, quotas, and the Go runtime client. No live project was invoked. Splitting, blueprints, confidence, and table rows matched the existing pipeline, but output layout and page indexing had to be pieced together from several guides and a sample notebook.

What worked

Custom-output pricing examples made per-page cost estimates straightforward. Async invoke and status APIs matched the generated Go client. Packet splitting and per-kind blueprints lined up with multi-document files and continuation table rows. Field-count limits were clear enough to size blueprints without a surcharge.

What got in the way

Docs did not make zero-based split page indices obvious, which produced a wrong page mapping until tests caught it. Status types suggested inline segments that the status call did not return, so results still had to be read from object storage. Image blueprints lacked confidence scores needed for review routing. A prerequisites page fetch returned almost no usable content.