Ask two brokers for the same data point and you will get two different words for it. One writes TIV, the next writes total insured value, a third labels a column values. One submission says GL, another general liability; a claim notice says DOL where the policy says date of loss. A generic extractor has to guess what each means — and guesses are exactly what you cannot audit.
A data glossary removes the guessing. It is a business-owned dictionary that tells the extraction agent: this is the field we care about, this is its standard name, this is what it means, and here are examples of good values. When the AI reads a document, the glossary grounds every field in your vocabulary instead of the model’s.
A curated P&C glossary library, organized the way underwriting thinks
InsightXtract ships a starter library of insurance glossaries grouped into three families — the Entity objects that appear across every deal, the Line-of-Business vocabularies, and the Claim (FNOL) glossaries. Each is a living, versioned, published artifact your team owns.
The objects on every deal
Submission, Insured, Broker, Claimant, Location, Vehicle, Coverage, Directors & Officers, Loss Run History — the shared nouns that recur across lines.
The specialist vocabularies
Casualty, Property, Commercial Auto, Workers’ Comp, Cyber, Professional Liability, Management & Financial, Environmental, Construction, Marine, Healthcare.
The first-notice details
Auto, Property, Workers’ Comp, and Cyber claim glossaries — the loss-specific fields adjusters and TPAs need captured on day one.
Inside a glossary: business terms the AI can trust
Open any glossary and you see the terms that ground extraction. Every term carries a standard name (the canonical field the data lands in), a plain-English description, and sample values that show the model what a correct answer looks like. Below is the Auto Claim Details glossary — the exact fields a first notice of loss should yield.
Where glossaries plug into the extraction flow
InsightXtract extraction is an agentic pipeline. Glossaries do their work at the Extract step — before the model ever produces a value, the terms for the relevant document class are compiled into the extraction prompt.
Glossaries power the highlighted step. Reference-code lookups power the last one — that’s Part 2.
Concretely, three things flow from a glossary term into the model:
- The definition grounds the prompt. The term’s description tells the model precisely what to look for, so “date of loss” is never confused with “date reported” or “policy inception.”
- Sample values act as few-shot examples. Showing that
police_report_numberlooks like “NPD-2026-44120” is the difference between recognizing a value and hallucinating a plausible one. - The standard name fixes where the data lands. However the broker labeled the column, the value is written to the canonical field — consistent across every submission and line of business.
Why sample values matter
Definitions tell the model what; examples tell it what good looks like. Together they turn a general-purpose LLM into one that reads your documents the way a seasoned underwriter would — and every extracted field traces back to the term that grounded it.
Why this matters to the business
- Accuracy you can audit. Every field traces to a glossary term, not a model’s best guess.
- Consistency across lines. The same vocabulary governs Casualty, Property, Cyber, and Workers’ Comp — a “date of loss” means the same thing everywhere.
- Owned by your team. Underwriting and data governance edit glossaries directly — no engineering ticket.
- Improves over time. Add a synonym or a sharper definition once, and every extraction afterward inherits it.
Next: from words to codes →
Glossaries decide what to capture. The companion post shows how reference-code lookup tables standardize those values — turning “commercial roofing contractor” into NAICS 238160 automatically.