Claim Graph

How Isomer structures inbound claims data into a queryable, ACORD-aligned graph that spans your entire book.

The claim graph is the structured data layer at the center of Isomer Core. Every inbound communication — email, fax, voice transcript, API feed — is processed and mapped onto a pre-built insurance ontology. The result is a customer-specific graph that spans every claim in your book and grows more complete with each message received.

Signals and Actions are both built on the claim graph. External AI agents can consume it directly via API or MCP.

Ontology

Isomer's ontology is aligned to ACORD standards and covers the full lifecycle of a claim. Each entity in the graph is a node; relationships between them are edges.

Claim and loss

The root of every claim subgraph. Captures loss date, loss description, line of business, claim number, and current status.

Involved parties

Party nodes are shared across claims where the same entity appears — enabling cross-claim pattern detection.

Policies and coverages

Policy number, effective dates, limits, sublimits, coverages in force, and deductibles. Used by coverage-related detectors in Signals and by Actions templates for coverage and benefit validation.

Documents and attachments

Every document is classified at the multi-segment level. A single PDF packet may yield multiple classified segments: medical records, legal correspondence, and billing invoices treated as distinct nodes. Classification is insurance-aware and robust to messy real-world inputs, including handwritten notes and scanned faxes.

Timeline

Events are ordered chronologically across the full claim lifecycle:

1. Incident
2. FNOL
3. Treatments and medical events
4. Legal filings and attorney involvement
5. Demands and settlement communications
6. Resolution

The timeline is what enables claim-lifecycle detection — Signals that require observing how a claim develops over time rather than a single document.

Relationships

Edges connect entities across the graph: a counsel node linked to a claimant, a document linked to both a provider and a timeline event, a party node linked across multiple claims. These relationships power cross-claim detection, including fraud ring and referral network signals.

How the graph is built

The graph is populated continuously. Each inbound message triggers document understanding, entity extraction, and relationship resolution:

1. Channel ingestion — message received via email, fax, voice transcript, portal, or API feed.
2. Document understanding — content extracted from the full original source; attachments processed individually.
3. Entity extraction — parties, dates, documents, events, and policy references identified.
4. Ontology mapping — extracted entities mapped to existing graph nodes or new nodes created.
5. Relationship resolution — edges created or updated to reflect new connections.

Structuring happens at arrival. There is no retroactive processing pass — the graph reflects the current state of every claim as of the most recent message.

Querying the graph

The graph is accessible via three methods:

# CLI — fetch a claim graph by claim number
isomer claims get CLM-00123

# API — retrieve all parties on a claim
GET /v1/claims/{claim_id}/parties

# MCP — available as a tool for external AI agents

See Core as infrastructure for full API and MCP reference.

Next steps