The glue-code tax: why extraction projects stall at the last mile

Every document-extraction pilot looks the same at demo time: a submission goes in, and out comes a clean, structured record with the fields highlighted and cited back to the page. The room nods. The business case gets signed. Then the project team discovers that the demo was the first ten percent of the work — and the remaining ninety percent has nothing to do with reading documents. It has to do with delivery: taking that pristine record and landing it, correctly, in every system that needs it.

That delivery layer is where the money and the calendar go. It rarely shows up in a proof-of-concept because a POC has exactly one consumer — a screen, or a spreadsheet the team eyeballs. Production has many: the PAS wants a bind-ready payload in its own schema; the rating engine wants a flattened, coded feature vector; the underwriting workstation wants a summary object with provenance; the claims system wants an FNOL record keyed to a claim number; and the source of record — SharePoint, a shared drive, or the broker email thread — wants the enriched result written back so the next person sees it. Each of those is a different shape, a different protocol, a different error-handling contract. And each one, done the usual way, is hand-written glue code.

What the last mile actually costs

The glue-code tax isn’t one big bill — it’s a hundred small ones that compound. Below is the hidden work that sits between “we extracted it accurately” and “it’s in the system, reliably, at scale.”

Hidden work item	Where it bites	Why it drains the budget
Bespoke field mapping per consumer	Per system	The extractor calls it named_insured; the PAS wants InsuredName1; the rating engine wants party.legal_name. Someone maps all 50+ fields, by hand, for every target — and re-maps them when either side changes.
Format & shape mismatch	Per system	Dates as MM/DD/YYYY vs. ISO; currency as string vs. cents; a nested loss table the rating engine needs flattened to one row per claim with prefixed columns. Reshaping logic multiplies.
Point-to-point scripts	Brittle	A cron job pulls JSON, transforms it, POSTs to an endpoint. It works until a field is null, the endpoint returns 429, or someone renames a column. No one owns it; everyone fears it.
Re-keying & manual paste	Ongoing	When the script can’t be justified, an operator copies values into the workstation by hand — the exact cost the automation was bought to remove, quietly reintroduced.
Round-tripping to the source of record	Often skipped	The enriched record has to be written back to SharePoint / the folder / the email thread so the record of truth stays current. Half of projects punt on this and end up with two versions of reality.
Error handling, retries, idempotency	Underestimated	What happens when the PAS is down for maintenance? When the same document is submitted twice? Production-grade delivery needs dead-letter queues, retries with backoff, and dedupe keys — none of which appear in a POC.
Observability & reconciliation	Afterthought	“Did all 400 of yesterday’s submissions actually land?” Without per-record delivery status and a reconciliation report, no one can answer — so trust erodes and shadow spreadsheets return.

Why every new consumer multiplies the code

The reason this pattern kills timelines isn’t any single item above — it’s the way they combine. When integration is written point-to-point, connecting N extraction outputs to M consuming systems tends toward N×M pieces of bespoke code, each with its own mapping, reshaping, transport, and error handling. Add a second document type and the count grows. Add a claims system alongside the underwriting one and it grows again. Every new consumer doesn’t add work — it multiplies it, because there is no shared contract in the middle for anyone to build against.

Concretely: a specialty carrier automates excess-casualty submission intake. The extraction is excellent. Then quarter two is spent wiring it to the PAS. Quarter three, the rating team asks for the same data in their shape — a new mapping, a new flattening pass, a new script. Quarter four, claims wants FNOL from a different document class — and because the first two integrations were point-to-point, none of that work is reusable. The project didn’t stall because the model got worse. It stalled because the integration surface grew faster than the team could hand-code it.

What good looks like

The way out is to stop treating delivery as an afterthought and give it a real architecture. Three ideas do most of the work: a stable canonical output, named adapters per consumer, and an API-first delivery model. Together they turn integration from a rebuild into a configuration change.

One extraction, one canonical record, many named adapters — add a consumer by adding an adapter, not by rebuilding the pipeline.

1. A stable, canonical output contract

The extraction produces one record shape — a well-defined, versioned schema that means the same thing regardless of which document the values came from or which system will consume them. This canonical record is the single thing every downstream integration builds against. When the extractor improves, the contract holds; when a consumer changes, only its adapter moves. The contract is the firewall between the two sides that, without it, are welded together by glue code.

2. Named output adapters, one per consumer

Each consuming system gets a named adapter that maps and reshapes the canonical record into exactly what that system demands — the PAS adapter emits its bind-ready schema, the rating adapter flattens the loss table into per-claim rows with the coded features, the round-trip adapter writes the enriched record back to SharePoint. The adapter is a declared, reusable unit of configuration, not a bespoke script buried in a cron job. Adding the claims system means adding a claims adapter — the extraction, the canonical record, and every other adapter stay untouched. That is what collapses the N×M explosion back down to N + M.

3. API-first delivery: poll or webhook

Delivery is exposed through a stable API, so systems either poll for completed records or are pushed results via webhook the moment extraction finishes. This is where the operational hard parts get solved once, centrally, instead of re-implemented in every script: authentication, retries with backoff, idempotency keys so a re-submitted document doesn’t double-post, dead-letter handling for a downstream that’s temporarily down, and a per-record delivery status you can reconcile against. The integration team writes against one documented API contract rather than reverse-engineering a pipeline.

Dimension	Point-to-point glue code	Canonical + adapters + API
Adding a new consumer	Rebuild	Add one named adapter; nothing else changes.
Cost of N outputs × M systems	~ N×M	~ N + M — the canonical record sits in the middle.
Error handling & retries	Per script	Solved once at the API / delivery layer.
When the extractor improves	Re-map each	Contract holds; adapters untouched.
Round-trip to source of record	Usually skipped	Just another named adapter.
Who owns it	No one	Configuration, versioned and observable.

Why it matters to the business

The last mile isn’t a plumbing detail — it’s where document-automation programs succeed or quietly fail. Treating it as architecture rather than glue code changes the economics of the whole initiative:

• Predictable timelines. When a new consumer is an adapter and not a rebuild, integration estimates stop ballooning. The second system takes days, not a quarter, because the canonical record and the delivery API already exist.
• Budgets that hold. The glue-code tax is paid in maintenance forever — every schema change, every downstream outage, every renamed field. Centralizing delivery converts that recurring drain into a one-time configuration.
• Reliability at scale. Retries, idempotency, dead-lettering, and per-record reconciliation mean 400 submissions a day actually land — and you can prove it. That is the difference between a system operations trusts and one they shadow with spreadsheets.
• No re-keying. A round-trip adapter writes results back to the source of record automatically, so the enriched data reaches the systems and the people who need it without an operator copying values by hand.
• Freedom to evolve. Because the extractor and the consumers are decoupled by a stable contract, you can improve extraction, swap a downstream system, or add a new document class without a cascade of integration rework.

The uncomfortable truth for anyone scoping a P&C extraction project is that accuracy is table stakes and delivery is the project. A vendor demo that ends at a clean extracted record has shown you the easy ninety-percent-of-the-value, ten-percent-of-the-work part. The questions that actually determine whether you ship are about the other ninety percent: Is there a stable output contract I can build against? Can I add a consumer without touching the pipeline? Is delivery an API my systems poll or subscribe to, with retries and reconciliation built in? When the answer is yes, integration becomes configuration — and the project reaches production on schedule instead of stalling at the last mile.