A raw extraction is only half the job. “Commercial roofing contractor” is not a NAICS code. “ABC Roofing, LLC” is not a customer record. “$1M/$2M” is not a coverage limit your rating engine understands. Lookup tables are how InsightXtract closes that gap — turning what the model read into the codes and keys your downstream systems actually run on.
Two jobs reference data does
Standardize to codes
Map free text to a controlled value — industry to NAICS / SIC, country and currency to ISO, and P&C sets like line of business, coverage type, cause of loss, and NCCI workers’-comp class.
Resolve to master entities
Match an extracted Insured, Broker, or Producer against your MDM master data — returning the canonical record and its key, not just a name string.
The reference library, comprehensive and authoritative
InsightXtract carries the full standard code sets — not samples — alongside P&C-specific vocabularies. They are managed as first-class tables your team can browse, search, edit, and extend.
Beyond the universal codes, the P&C library includes the vocabularies underwriting and claims live in: Lines of Business, Coverage Types, Cause of Loss / Perils, Claim Status, Document Types, Construction / Occupancy Types (ISO), and NCCI WC Class Codes.
Bring your own master data: MDM & entity resolution
The most valuable reference data is your own. Import a CSV — or connect your MDM hub — and InsightXtract treats your master registries as lookup tables. Now extraction does not just read a name; it resolves it. An extracted Insured or Broker is matched against your golden records and returns the master key, so every downstream system speaks in the same IDs.
Because the match returns your key, duplicate-free: “ABC Roofing LLC,” “ABC Roofing, L.L.C.,” and “Abc Roofing” all collapse to INS-00184. That is entity resolution happening at the point of extraction — before the data ever reaches your policy admin, data warehouse, or claims system.
Why resolve at extraction time?
Resolving names to master keys downstream means every consuming system re-solves the same problem — inconsistently. Doing it once, in the extraction pipeline, means clean, keyed, deduplicated entities flow everywhere after, and the match is captured with a confidence score you can threshold and audit.
How the matching works: exact, alias, and semantic
Lookups resolve in layers, cheapest first:
- Exact & alias match — the value equals a code, display name, or a known synonym (e.g. “gl” → General Liability). Instant and deterministic.
- Semantic match — when there is no exact hit, the value is embedded and compared to every entry by meaning, returning ranked candidates with scores. This is what lets “commercial roofing contractor” find Roofing Contractors even though those words never appear together in the table.
Where lookups plug into the extraction flow
If glossaries power the Extract step, lookups power the Standardize step that follows validation — the last thing that happens before data leaves the pipeline.
Lookups power the highlighted step. Glossaries power the Extract step — that’s Part 1.
The output of that step is clean, coded, resolved records — ready to flow onward with no manual cleanup:
Why this matters to the business
- Straight-through processing. Coded, entity-resolved data means fewer records bouncing to a human, and faster quote and claim turnaround.
- One version of the truth. Resolving to MDM keys at extraction keeps every downstream system aligned on the same customers, brokers, and codes.
- Auditable confidence. Every match carries a score you can threshold — auto-accept the strong ones, route the uncertain ones for review.
- Your data, extensible. Import a CSV or connect MDM; the same tables the AI uses are the ones your governance team curates.
← Start with the vocabulary
Lookups standardize the values that glossaries decide to capture. If you haven’t read it, Part 1 on glossaries & business terms covers the other half of the story.