Most write-ups tell you a platform “extracts submissions.” This one shows the work. We take a real excess-casualty packet — a national contractor, Cornerstone Infrastructure Group, marketing a $25M lead umbrella — and walk it through InsightXtract end to end: classification, field & schedule extraction with page-level citations, glossary normalization, deterministic derived exposures, and the final governed underwriting record. Every result below is an actual output shape from the agent.
The packet
Four files, four very different shapes — the everyday reality of an excess submission.
- broker_email.pdf — a three-message renewal email chain: account narrative, sector/project-type breakout, current limits & retentions, and three excess-layer options.
- rfq.pdf — a seven-section request-for-quote (General Info, Corporate Overview, CGL, Auto, WC/EL, Umbrella, 5-year Loss History).
- operations_exposure.xlsx — a seven-sheet operations workbook: GL exposure, WC payroll, vehicle schedule, driver list, named-insured mix, location SOV.
- project_financials.xlsx — a seven-region contractor WIP workbook with stacked group headers and 1,330 project rows.
Step 1 — Classification
Before extraction, the agent routes each file to a document type. Classification is evidence-bearing: it returns the class, a confidence, and the signal it keyed on — not a black-box label.
A single submission can carry many more types — ACORD 125/126/127/129/130/131, schedule of underlying, 5-year loss runs, and full carrier-issued layer policies from other markets. Each routes to its own typed extractor.
Step 2 — Field extraction with citations
Each document is extracted against its type’s schema. Every value carries a citation — the page (and region) it came from — so an underwriter can click straight to the source. Here is the coverage structure the agent read from the broker email and RFQ:
Citations aren’t decoration — they’re the audit trail. Every field the agent emits is grounded to a page/region, which is what makes the output defensible for a file review or a regulator.
Step 3 — Reading the exposure workbook
The operations workbook is where naive extractors fail: seven sheets, hundreds of rows, sub-tables, and — in the WIP workbook — stacked group headers. InsightXtract reads every sheet, classifies each region (metadata block vs. table), flattens grouped headers, and maps each sheet to a typed schedule. Nothing is dropped. Sample of the GL exposure schedule, with codes normalized against glossaries:
| Division | State | WC Code | Description | Revenue | Payroll |
|---|---|---|---|---|---|
| MIQ | LA us_state_codes | 91583 ncci | Masonry | $31,131,000 | $5,345,945 |
| WEST | CA | 95410 | Plumbing – Commercial | $18,470,000 | $3,112,600 |
| SOUTH | TX | 92215 | Electrical – Within Buildings | $24,905,000 | $4,610,880 |
| … 52 rows total · workers_compensation 150 · automobile 66 · driver_list 64 · named_insured_mix 46 · location_list 36 | |||||
Each column is bound to a reference vocabulary — state → us_state_codes, class → ncci_wc_class_codes, vehicle type → vehicle_body_types, occupancy → occupancy_types — so raw broker wording lands as canonical codes, and out-of-vocabulary values are flagged, not silently kept.
Step 4 — Derived exposures (deterministic, not guessed)
Underwriters price on totals: payroll, unit counts, revenue. Asking an LLM to add up 150 rows is slow and unreliable. Instead, the document type declares derived fields — sum, count, group_by — that compute deterministically over the extracted rows. Exact every time, and each traces back to its schedule:
The last tile is a cross-region total — summed across all seven WIP sheets via a wildcard rule, so it stays correct no matter how many regions a broker’s workbook happens to have (1,330 projects here).
Step 5 — One governed record
Per-document outputs are consolidated into a single underwriting record: fields resolved by source priority, schedules carried through as typed tables, derived exposures attached, and every value kept with its provenance. A slice of the unified output:
"insured_name": "Cornerstone Infrastructure Group, Inc.",
"umbrella_lead_limit": 25000000,
"gl_payroll": 177816199, // derived · ∑ general_liability.payroll
"wc_payroll": 245751000,
"number_of_autos": 66,
"tables": { "general_liability": [52 rows], "workers_compensation": [150], "automobile": [66] },
"_provenance": { "gl_each_occurrence": { "source": "application", "page": 2 } },
"metadata": { "validation_errors": [], "config_version": 4 }
}
Why this holds up in production
- Every value is cited — page/region provenance on fields and schedules; nothing is unsourced.
- Codes are normalized against governed glossaries; out-of-vocabulary values are validated, not hidden.
- Totals are computed, not guessed — deterministic derived fields over the extracted rows, exact and reproducible.
- Configuration is versioned — the document types, glossaries and rules are pinned to a published version, so an output made today reproduces tomorrow.
- Nothing is dropped — the all-sheets extractor surfaces every schedule, even ones the base schema didn’t anticipate.
See it on your own submissions
InsightXtract ships an Excess Casualty agent with typed schedules, glossary-normalized codes, validation, and deterministic derived exposures — configurable per carrier and broker template. Talk to us for a walkthrough on your own packets.