Standardizing a value and resolving an identity are different problems. Turning “Calif” into CA is standardization — a closed set with a right answer. But brokers, insureds, and producers are open, growing sets of real-world entities that arrive spelled a dozen ways, abbreviated, misordered, and misremembered. “Apex Ins. Brokers” and “Apex Insurance Brokers, LLC” aren’t a code to look up; they’re the same organization, and something has to decide that.
If it doesn’t, the damage is quiet and cumulative: the same broker appears as five records, submission counts are wrong, you can’t roll up experience by insured, and writing back to a policy system creates duplicates. InsightXtract addresses this where the data is born — at extraction — by resolving each extracted party against an entity registry of canonical identities.
Standardize vs. resolve
| Standardize (lookups) | Resolve (entity registry) | |
|---|---|---|
| Applies to | Closed code sets — states, currencies, ISO classes | Open, growing entities — brokers, insureds, producers |
| Answer | The canonical code (CA) | A canonical id (#B-1024) + confidence |
| Method | Alias match | Fuzzy + embedding match against known entities |
| Uncertain? | Flag as unmatched | Low-confidence → a person confirms or creates |
(Standardization has its own post — see declarative post-processing. This is the harder, open-set cousin.)
How resolution works
Each extracted party name is matched against the registry using both fuzzy string similarity and semantic embeddings — so a reworded or abbreviated name still finds its canonical record. The output is the canonical id, the clean name, and a confidence. Above the threshold, the entity is resolved automatically; below it, the case routes to a person to confirm the match or create a new canonical entity — which then makes every future occurrence resolve cleanly.
{ "broker": {
"raw": "Apex Ins. Brokers",
"canonical_id": "B-1024",
"canonical_name": "Apex Insurance Brokers, LLC",
"confidence": 0.94, "pas_ref": "PROD-BR-4471" } }
“Apex Ins. Brokers”"] --> R{resolve
fuzzy + embedding} R -->|high confidence| M["canonical id #B-1024
+ pas_ref"] R -->|low confidence| Q[review queue
confirm or create] Q --> REG[(entity registry)] M --> REG REG -. sync .- PAS[(policy system)]
The registry keeps a canonical record per entity — its id, its aliases, and a reference into your policy system — and stays in step with that system, so the identities InsightXtract resolves to are the same ones your book already knows. Each confirmed match adds an alias, so the registry gets smarter with use.
Why resolving at extraction matters
- Write-back that doesn’t duplicate. Resolving to a canonical id — with a reference into the policy system — means results land on the right existing record instead of spawning duplicates.
- Analytics that roll up. Experience by broker, concentration by insured, submission counts — all require that every mention of an entity collapses to one identity.
- Uncertainty handled, not hidden. A shaky match becomes a review, not a silent wrong merge — and the human’s decision improves every future run.
- Clean data at the source. Fixing identity at extraction is far cheaper than de-duplicating a warehouse after the fact.
The registry is an asset that compounds
Every resolution — automatic or confirmed — enriches the registry with another alias and another data point. Over time the open-set problem shrinks: the entities a carrier actually deals with become well-known, and new documents resolve against them with less and less human input.
Read next →
See the model these identities live in: the connected entity model, the closed-set cousin: lookups, and where clean identities get written back: folder-native intake and round-trip.