Unified data infrastructure
GitHub Let's talk

Insurance

Policies, documents and claims from one customer view.

Insurance is document-heavy and relationship-heavy: a policy is a set of obligations, a claim is a set of evidence, and risk is a property of how those connect.

See Risk & Fraud All of Financial Services

A claim read against the policy, the asset and the history at once.

The story

A claim read against the policy, the asset and the history at once.

Where it starts

Policies and endorsements

Cover, limits, parties and the changes made over time. It is the first of 4 workloads running in Insurance.

The question it raises

Claim against policy

Cover, endorsements and history resolve from one request instead of a document hunt.

Why one question is hard

From Quote to Settle

Insurance data moves through 4 stages — Quote → Underwrite → Claim → Settle. The shapes in play are SQL, JSON / documents, Graph, Objects, Time series, and answering one question means reading across all of them.

What PLOMID contributes

Underwriting and claims ask for structure and evidence at the same time. These are the parts that keep them together.

  • Documents beside rows Fields that keep changing shape stay queryable instead of being exported into a separate document store.
  • One data layer Rows, documents and time-ordered events live in one system, so a question is asked once instead of once per store.
  • Relationships held as data Edges expressed directly remove the reconstruction that happens at query time when relationships live in a join.
The environment

Policies, claims, risk factors and the documents behind every decision.

Policies are structured records, claims arrive as documents and forms, and risk decisions depend on relationships between parties, assets and history. PLOMID keeps the structured policy data, the documents and the relationships in one layer, so a claim can be read against the policy, the asset and the history at once.

Where the data goes to work

Questions money asks repeatedly.

Each one reads records, and where it must, the relationships between them — from the same layer, not an extract.

Claim against policy

Cover, endorsements and history resolve from one request instead of a document hunt.

  • SQL
  • Graph

Relationship risk

Broker, party and asset relationships sit beside the policies they influence.

  • SQL
  • JSON / documents

Evidence stays searchable

Reports and attachments keep queryable metadata rather than living in a folder tree.

  • JSON / documents
  • Objects

Loss analysis

Severity and timing measurements compute over the same policies and claims they describe.

  • SQL
  • Time series
The data journey

How insurance data reaches one layer.

Walk the path the data takes, from the environment that produces it to the questions it answers. Select a station, or a shape, to read each step.

A claim read against the policy, the asset and the history at once.

Environment

The policy

Cover, limits, parties and endorsements as structured records.

SQL

Data models in play

The shapes, in one layer.

5 shapes carry this domain. Choose a stage to read the operation, or a shape to see every stage that handles it.

PLOMID · Insurance quote · underwrite · claim · settle Select a stage
Stage

Quote

Risk factors, party records and asset details

SQL · Graph

Workload map Insurance workload map. Every shape on it is a surface of the layer, and each stage names the part of the operation it carries.
  • SQL Records, keys and joins
  • JSON / documents Documents and nested objects
  • Graph Relationships and traversal
  • Objects Large assets with queryable metadata
  • Time series Measurements and events in time order
One environment · many workloads

What runs against insurance data.

4 workload families over one set of shapes. Choose one to see what it moves and where it lands.

Cover, limits, parties and the changes made over time.

  • Planned once against the layer, not once per store
  • Read beside the records it shares a key with
  • Persisted under one storage contract
Workload architecture

From posting to traversal.

Records first, relationships where the question needs them — every path a request can take through this data.

Insurance · workload architecture
Workloads

What runs against this data.

  • Policies and endorsements
  • Claims and evidence
  • Risk and party relationships
  • Loss and decision signals
Data models

The shapes those workloads read and write.

  • SQL
  • JSON / documents
  • Graph
  • Objects
  • Time series
The layer

One path from a request to the data it names.

  • Planning Predicates narrow the work before it runs
  • Execution Records, fields and windows answered together
  • Transactions Readers and writers do not block each other
Surfaces

How the work reaches the layer.

  • SQL surface The query language the layer is documented in
  • Applications Services and jobs writing and reading as they run
  • Analytics & AI clients The same layer, the same access path
Deployment & residency

Where this data is allowed to run.

Claims and underwriting data are held inside the institution, with residency stated as direction rather than claimed.

Deployment, residency and control
What you build next

Risk & Fraud

Decisions made across transactions, entities and their relationships.

If Claim against policy is your question, start here.

See Risk & Fraud Every solution
Next

Where to go next

Solutions The workload answers this industry leans on, with their models and status. Platform The data models in the product today, and the ones extending the layer. Architecture How a request is planned, executed and persisted once it reaches the layer.