Knowledge Graphs

Knowledge graphs provide a structured way to represent real-world entities, their attributes, and the relationships among them. In property and casualty insurance, they can connect fragmented information across claims, policies, insureds, claimants, providers, attorneys, vehicles, properties, documents, transactions, exposures, and events—while preserving context and provenance.

Executive premise A knowledge graph does not merely store facts. It makes relationships explicit, traceable, and computable. That allows insurance teams and AI systems to reason over connected evidence rather than treating every record or document as an isolated object.

Editorial note: Examples in this chapter are illustrative and should be adapted to each carrier’s products, jurisdictional requirements, data rights, operating model, and model-risk framework.

One-sentence definition A knowledge graph is a connected, machine-readable representation of entities, concepts, events, documents, and the relationships among them, usually enriched with business meaning, source provenance, and rules.

Insurance information is inherently relational. A bodily injury claim connects an accident, a policy, multiple vehicles, drivers, passengers, medical providers, diagnoses, treatments, attorneys, demands, reserves, payments, and litigation events. Traditional systems often store these facts in separate tables, files, applications, and documents. A knowledge graph creates an enterprise relationship layer that makes those connections explicit.

The business value is not the graph itself. Value emerges when the graph enables faster investigation, more complete context, earlier pattern detection, better search, stronger explainability, reusable institutional knowledge, and more reliable AI. The graph can support human users directly through relationship views and semantic search, or indirectly as a grounding layer for predictive models, retrieval-augmented generation, and AI agents.

Knowledge graphs are particularly useful when the organization needs to combine structured and unstructured data; preserve source and time context; reconcile multiple identifiers; expose many-to-many relationships; reason over networks; or provide evidence trails for an AI-generated conclusion.

They are not a replacement for policy, claims, billing, document, or data-warehouse systems. A well-designed graph complements those systems by connecting their information through a governed semantic model. The design challenge is therefore as much organizational as technical: define the concepts, ownership, identifiers, relationships, provenance, access controls, and lifecycle rules that make the graph trustworthy.

Executive Definition

A knowledge graph is an enterprise knowledge layer that connects information about business objects and events so people and systems can understand not only what is known, but how the facts relate and where they came from.

A knowledge graph is a graph-structured data representation in which nodes represent entities or concepts, edges represent typed relationships, and properties describe nodes or edges. The graph is typically governed by an ontology or schema and may support inference, semantic constraints, temporal modeling, provenance, embeddings, and graph analytics.

In P&C insurance, a knowledge graph represents connected knowledge about policies, coverages, claims, losses, people, organizations, locations, assets, providers, attorneys, documents, transactions, exposures, and events. It enables carriers to trace how facts and evidence are related across the claim and policy lifecycle.

A graph database is a technology for storing and querying graph-shaped data. A knowledge graph is the business and semantic asset created by combining graph data, definitions, relationships, provenance, governance, and intended uses. A carrier may implement a knowledge graph with a native graph database, an RDF store, relational technology, a cloud data platform, or a combination of technologies.

The Operating Pattern

Consider a commercial auto loss. The graph might contain nodes for the claim, policy, insured organization, tractor, trailer, driver, claimant, accident location, police report, medical provider, attorney, demand letter, reserve transaction, and lawsuit. Relationships connect the driver to the vehicle, vehicle to claim, claimant to treatment, attorney to claimant, demand to document, document to extracted facts, and every fact to its source and effective date.

Illustrative graph statement

Graphs magnify both good and bad identity decisions. Linking two records that belong to the same provider can reveal meaningful network patterns. Linking two different people with similar names can produce a false narrative. Identity resolution should therefore use approved identifiers, normalization, probabilistic matching, confidence thresholds, conflict rules, temporal evidence, and human review for consequential cases.

Insurance facts change. A claimant may retain counsel after initial contact. A policy endorsement may alter coverage. A provider address may change. A reserve may be revised repeatedly. The graph should distinguish event time, effective time, discovery time, and system load time when those distinctions affect interpretation. Replacing an old fact without preserving history can destroy the evidence needed to understand a decision.

Every material fact should be traceable to an authoritative system, document, page, communication, external source, or approved inference. Extracted facts may also need confidence scores and review status. Provenance allows a professional to inspect the evidence instead of accepting an unexplained graph assertion.

Why Ontology Design Matters

The ontology determines what the graph means. Without clear definitions, the graph becomes a collection of loosely connected records that different users interpret differently. Insurance ontology design should be driven by business questions, regulatory context, source-system realities, and the decisions the graph is intended to support.

A successful program usually begins with a focused ontology aligned to one or two high-value use cases. Attempting to model the entire carrier at once can create prolonged design work with little operational value. The minimal ontology should still include stable identifiers, provenance, time, confidence, ownership, and extensibility so that later use cases do not require a complete redesign.

Claims teams frequently need to understand a network, not a record. A graph can help an investigator see that multiple claims involve the same provider group, repair facility, attorney office, address, phone number, vehicle, employer, or pattern of documentation. The graph does not establish wrongdoing. It organizes connected facts so qualified professionals can determine whether additional review is warranted.

Coverage analysis depends on the policy version, endorsements, effective dates, insured roles, property or vehicle schedules, jurisdiction, and loss facts. A graph can connect the applicable contract components to the claim evidence and preserve the path from a coverage question to the relevant policy language. Final coverage decisions remain with authorized professionals.

A graph can connect insured locations, parent organizations, suppliers, infrastructure dependencies, policies, perils, and event footprints. This can reveal indirect concentration that is difficult to see in a location-only view. Temporal and geospatial models may be combined with graph relationships to support catastrophe response and portfolio management.

Knowledge graphs improve search by adding semantic context. A user searching for a provider can retrieve aliases, related organizations, relevant claims, source documents, locations, and time periods. The graph can also constrain retrieval so an AI assistant receives only facts and documents connected to the approved task and user permissions.

Scenario: Complex Commercial Auto Bodily Injury Claim

A commercial auto claim begins as a reported intersection collision. Initial facts suggest moderate vehicle damage and soft-tissue injury. Over the next several months, new treatment, representation, diagnostic findings, wage-loss allegations, and a policy-limits demand emerge across emails, medical records, bills, police materials, and claim-system notes.

The graph shows that the claimant began treating at an urgent-care facility, later visited an orthopedic practice, received imaging, and was referred to a surgical specialist. It also shows the timing of attorney involvement, the first surgery recommendation, reserve changes, and the eventual demand. A claims professional can traverse from each asserted fact to the source document and review whether the relationship is observed, extracted, or inferred.

A RAG application uses the graph to assemble a task-specific subgraph: applicable policy, involved parties, injury timeline, treatment providers, major medical findings, demand allegations, reserve history, and source documents. The LLM produces a structured summary with citations. A predictive model may use approved graph-derived features, such as treatment progression or legal-event timing, but the model output is presented as decision support rather than a liability or settlement decision.

The carrier may achieve faster file orientation, more consistent escalation, fewer missed relationships, better reserve-review preparation, and stronger auditability. Outcome measurement should compare the graph-enabled workflow with a baseline and control for claim mix. The goal is improved information and professional action, not automatic claim disposition.

Scenario: Multi-Location Commercial Property Submission

An underwriter receives a submission containing applications, schedules of values, loss runs, engineering reports, statements of values, corporate documents, and broker correspondence. Locations appear under slightly different names, subsidiaries share ownership, and some properties depend on common utilities and suppliers.

The graph powers a workbench that presents the account hierarchy, locations, values, hazards, loss history, recommendations, and supporting documents. The underwriter can select a location and see all related information, or begin with a recommendation and trace it to the affected building, inspection report, status update, and proposed term.

The same representation can connect the prospective risk to existing portfolio concentrations, provided access and governance rules permit. The underwriter may see that several insured locations depend on the same logistics hub or occupy buildings owned by a common landlord. This relationship context can inform referral or aggregation review without replacing underwriting authority.

AI can identify missing schedules, inconsistent addresses, unverified construction attributes, stale engineering information, or connected concentration. The underwriter retains authority over appetite, risk selection, pricing inputs, terms, conditions, and referrals. The graph should make evidence easier to inspect and should clearly distinguish submitted facts, third-party data, inferred relationships, and professional conclusions.

Graph-Enhanced Retrieval-Augmented Generation

Traditional RAG often retrieves text chunks based on lexical or vector similarity. Graph-enhanced RAG can first identify relevant entities and relationships, then retrieve documents connected to that subgraph. This helps the system assemble context around the actual claim, policy version, party role, event sequence, or insured location rather than relying only on semantic similarity.

The graph can provide structured facts and evidence paths to an LLM. A generated answer should cite the underlying sources and avoid converting uncertain or inferred graph relationships into definitive statements. The application should disclose whether a fact came from a core system, a document extraction, a third-party source, a human conclusion, or an inference rule.

An agent may use the graph to plan and execute bounded tasks—for example, gathering claim context for a reserve review, checking whether requested submission documents are present, or preparing a referral package. The graph can constrain tool access and give the agent a consistent view of entities and permissions. Consequential actions should require approval, and the agent’s traversal, retrieval, and outputs should be logged.

Graph-derived features can capture network degree, relationship counts, temporal sequences, community structure, path patterns, or connected exposures. These features can improve predictive models, but they can also create hidden proxies or guilt-by-association effects. Feature approval, fairness review, stability testing, and business interpretation are essential.

Graph neural networks learn representations from graph structure and node or edge attributes. They may support link prediction, classification, anomaly detection, and network analysis. Their complexity can make interpretation and governance more difficult. A carrier should use them only when simpler methods do not meet the business need and when the organization can validate, monitor, and explain the model appropriately.

Executive caution A large graph is not evidence of business value. The meaningful question is whether connected, governed knowledge improves a specific workflow, decision, control, or customer outcome.

Association is not proof A shared address, provider, attorney, repair facility, phone number, or other network connection may be legitimate. Graph relationships should support investigation and prioritization, not automatic allegations, adverse action, or unsupported conclusions.

A graph can expose relationships that individual source systems would not reveal in one view. Access should therefore be enforced at the entity, property, relationship, document, and purpose level when appropriate. The system should preserve the user’s source-system entitlements rather than using the graph as a path around them.

For material uses, the carrier should be able to reconstruct which source facts, relationships, ontology version, retrieval path, model version, and user actions contributed to an output. Corrections should not erase historical evidence needed for audit, dispute resolution, or regulatory review.

Phased Implementation

When a Knowledge Graph Is a Strong Fit

Proceed when The use case has measurable relationship complexity; the ontology and authoritative sources are defined; identity and provenance controls are operational; access is purpose-limited; professional review is embedded; and the expected workflow value justifies ongoing stewardship.

For insurance AI, connected context is often more important than a larger model. A claim outcome is rarely explained by one document, one field, or one event. It develops through relationships among people, injuries, providers, attorneys, communications, venues, reserves, and decisions over time. A knowledge graph can organize that context into a form that both professionals and governed AI systems can use.

The strongest design is evidence-first. Every surfaced relationship should lead the professional back to the underlying source. Extracted facts should be labeled as extracted. Inferred links should be labeled as inferred. Model predictions should remain distinct from verified claim facts. This separation helps the organization use AI without blurring evidence, interpretation, and decision authority.

A knowledge graph can also help bridge legacy environments. Rather than requiring wholesale replacement of core platforms, the graph can connect policy, claims, document, communication, and analytics sources through secure integration patterns. It becomes a governed context layer embedded into existing workflows.

People-plus-AI principle The graph should help claims professionals, underwriters, managers, and investigators see connected evidence earlier and act with greater confidence. It should not make unreviewed coverage, liability, fraud, pricing, settlement, or employment decisions.