Inside a product recall submission: what InsightXtract extracts — and why it matters

Product recall — contaminated products, product guarantee, recall expense — is a deceptively compact line to intake. Unlike an excess casualty packet with a dozen files, a recall submission usually arrives as just two documents: the broker’s email with the ask, and a recall application. But the information that actually decides the price — the mix of products the insured makes, the annual revenue behind each, how broadly they distribute, and what has already gone wrong — sits inside those two files in prose paragraphs and embedded tables, and it is almost never on any one line.

Most intake tools read one document at a time and hand back a flat list of fields. That is not how a recall account is underwritten. InsightXtract runs an agentic, multi-document pipeline that classifies each file, extracts to a per-document schema, consolidates everything into one unified account record, links it into an entity graph, and validates it against your rules — so the underwriter opens a single, coded, cited record instead of two PDFs.

One submission, two documents, one connected record — classify, extract, consolidate, link, validate.

The idea that governs everything: distribution breadth is the cost of a recall

Before the categories, the single most important concept. In product recall, the loss is not the defect — it’s the reach. A contaminated batch that never left the plant costs almost nothing; the same batch, distributed nationally through big-box retail, costs millions in retrieval, destruction, notification, and lost-gross-profit. So the parameters that matter most are the ones that describe reach and volume: what products the insured sells, how many units ship each year, the revenue behind them, and the regions they distribute into. Two accounts with identical products price very differently once you know one ships regionally and the other ships to forty countries.

The second governing idea is prior recalls. A clean recall history and a history of three FDA-driven pulls are not the same risk, and the recall history table is where that story lives — captured as one row per event. In the tables below, the Captured column flags how each item is pulled:

• Point-in-time — a single static fact about the account.
• Current — captured once for this term (the coverage being requested).
• Per-row — a table: one product per row, or one prior recall per row.
• Historical — a prior event captured for its trend and severity signal.

A · The insured & identity

Who the account is — legal identity, location, operations classification, and tenure. This is the account key everything else hangs off. Source: recall application.

Parameter	Captured	Why it matters
Insured name · DBA name · FEIN	Point-in-time	The contract party and unique account key — drives clearance, conflicts, and de-dupe.
Insured address · city · state · ZIP	Point-in-time	Domicile, venue, and the state code standardized against reference data.
Business description · NAICS code · entity type	Point-in-time	Class-based rating and appetite/knockout — the food, pharma, or auto-parts hazard grade.
Years in business · website	Point-in-time	Stability credit and a public-facing view of the product line and brand exposure.

B · Broker & submission

Who is placing the account and what kind of transaction this is — the distribution chain and routing. Source: broker email.

Parameter	Captured	Why it matters
Broker name · broker company	Point-in-time	Distribution routing, binding authority, and the relationship behind the ask.
Broker email	Point-in-time	Correspondence channel and the audit trail for the submission thread.
Submission type	Current	New vs. renewal — sets the workflow and whether a rate-change baseline exists.

C · The products profile — where the exposure lives

This is the heart of a recall risk: what the insured makes, how much revenue rides on it, and how far it travels. Source: recall application.

Parameter	Captured	Why it matters
Products description	Point-in-time	The nature of the goods — perishable food, infant formula, or auto parts — sets the recall severity and regulatory regime.
Annual product revenue	Current	The primary exposure base — lost-gross-profit and third-party recall costs scale with it.
Distribution regions	Point-in-time	Reach is cost: national or export distribution multiplies retrieval, destruction, and notification expense.

D · Coverage & limits — the exact shape of the ask

The requested cover — limits, retention, price, and layer position — the core of what the underwriter is being asked to put up. Source: recall application.

Parameter	Captured	Why it matters
Requested limit	Current	The capacity being asked for — the starting point of the ask.
Each-occurrence limit · aggregate limit	Current	Per-event capacity and total annual capacity — how many recalls the tower absorbs.
Deductible · retention	Current	The insured’s own skin in the game — drives net exposure and moral hazard.
Premium	Current	The target price to measure rate adequacy against the exposure and history.
Primary or excess	Current	Layer position — primary attachment vs. excess drives burn-through risk and price.
Effective date · expiration date	Current	The term and binding deadline, standardized to a single date format.

E · The product schedule — one row per product

A single “products revenue” number hides the mix. InsightXtract reads the product schedule as a table — one row per product — so the underwriter sees which SKUs carry the volume, the revenue, and the geographic reach. Source: recall application.

Parameter	Captured	Why it matters
Per product: product	Per-row	The named SKU or line — a high-risk item (infant formula, ground beef) changes the whole account grade.
Per product: annual units	Per-row	Unit volume in the field — the direct driver of how many units a recall must retrieve.
Per product: revenue	Per-row	Revenue concentration — a single dominant product is a single point of failure.
Per product: distribution region	Per-row	Per-SKU reach — the export lines are where recall cost concentrates.

F · The recall history — one row per prior recall

The single biggest pricing input after reach. InsightXtract reads each prior recall as a row — when it happened, what was pulled, why, what it cost, and how many units were affected. This is where a clean account separates from a repeat offender. Source: recall application (plus the prior-recalls narrative).

Parameter	Captured	Why it matters
Per recall: date	Per-row	Recency and frequency — three recalls in five years is a very different risk from one a decade ago.
Per recall: product	Per-row	Ties the event to a line — a recurring product signals a systemic quality problem.
Per recall: cause	Per-row	Contamination, mislabeling, or manufacturing defect — the root cause drives whether it recurs.
Per recall: cost	Per-row	The realized severity of past events — the best available proxy for the next loss.
Per recall: units affected	Per-row	The scale of each event — ties cost back to volume and validates the exposure base.

Alongside the structured table, the application’s free-text prior-recalls narrative is captured as a field of its own, so nothing in the broker’s description is lost even when it hasn’t been tabulated.

From two documents to one connected record

Pulling these parameters out of two documents is only half the job. The value is in consolidation: the insured named on the application, the broker on the email, the products in the schedule, and the events in the recall history all describe one account. InsightXtract merges them into a single record by a declared source-of-truth priority (the application wins on insured and coverage details; the email supplies the broker and submission type), and links the result into an entity graph — insured at the centre, connected to broker, submission, products profile, coverage, the product schedule, and the recall history.

Why it matters to the business

Comprehensive, structured extraction of a recall submission isn’t a data-entry nicety — it changes the economics and quality of the book:

• Reach-aware pricing. Capturing distribution regions at the account level and per product means you rate to the true cost of a recall — the breadth of the field — not just the revenue number on the front page.
• Prior recalls surface by default. The recall history — date, product, cause, cost, units affected — is exactly the part that predicts the next loss, and exactly the part that gets skimmed under time pressure. Extracting it as structured rows means it reaches the underwriter, not the claim file.
• Product-mix visibility. The per-product schedule exposes concentration — a single dominant SKU, a high-risk line, an export-heavy product — that a single blended revenue figure would hide.
• Faster quotes. An underwriter opening a consolidated, cited record instead of an email and a PDF triages and prices in minutes — more submissions handled without more headcount.
• Consistency and auditability. The same fields, coded and validated the same way every time — state codes and NAICS checked against reference data, limits and dates normalized, insured name required — with provenance to the source document.

The Product Recall agent extracts all of this today — the insured and identity block; the broker and submission; the products profile of description, annual product revenue, and distribution regions; the full coverage tower of requested, each-occurrence and aggregate limits, deductible, retention, premium, layer position, and term; the per-product schedule; and the prior-recall history — consolidated into one coded record with provenance, confidence, and validation on every value. The point this post makes is why it matters: reach and prior recalls are what move a recall price, so they’re captured by default. And because it’s all configuration — fields and tables in the agent’s output contract, not code — the schema keeps pace with what underwriters ask for.