The Chubb Enterprise Knowledge Graph, built virtual-first.

The strategy, up front

This is not a proposal to build another data store. It is a proposal to build a semantic access layer. The data stays where it lives — in Guidewire, in policy-admin systems, in the lakehouse — and the knowledge graph provides one governed, machine-reasonable vocabulary for asking questions across all of it. That choice, Ontology-Based Data Access (OBDA), is the spine of everything that follows.

The document is written for the people who will build it. It moves from principles to a reference architecture, then through the four systems that make a virtual graph real — the semantic layer, the mapping-and-federation fabric, entity resolution, and executable governance — to the serving layer and a phased roadmap. It builds on the four ontology-engineering briefs in this series: the questions that drive scope, the message anti-pattern that keeps the model clean, modularization that structures it, and the namespace policy that names it.

The Enterprise Knowledge Graph exists to answer questions that span systems — What is this customer’s total exposure across every policy and open claim? — in one vocabulary, traceably, over authoritative data. Its value is meaning and connection, not storage. Every architectural decision below descends from seven principles.

The stack reads bottom-up: authoritative data at the base, a thin declarative fabric that lifts it into the ontology, and a serving layer that hands one graph to many consumers. Governance, catalog and security run vertically through all of it.

The current ontology is the strongest asset in the programme: modular (fnd/ → ins/ → misc/), reasoned under OWL 2 DL, shaped by SHACL, and driven by competency questions. Three changes turn it from a domain model into the contract an enterprise graph runs on.

In a virtual graph, mappings are the integration. A SPARQL query never touches a source directly; it is rewritten, through the mappings, into queries the sources can run. Two things must be first-class: the mappings themselves, and the federation that joins across a mixed substrate.

Mappings as governed modules

• One mapping module per source, mirroring the ontology’s seams. A source’s policy tables map to the policy vocabulary; its party tables to the party vocabulary. Mappings are versioned in source control and reviewed like code.
• Target the contract, never a sibling’s internals. Every mapping emits terms from the shared ontology. That is what lets two different source systems answer the same question through one query.
• Test mappings against competency questions. A mapping is complete when the CQs it is meant to satisfy return correct results over that source — the same acceptance discipline, applied to integration.

Federating a mixed substrate

Because domains sit on different substrates — some on the curated lakehouse, some directly on operational systems — the layer needs a planner that can join across sources and push work down to each. Two viable shapes, chosen per the engine you standardize on:

In a federated virtual graph, the central difficulty is not access — it is identity. The same customer is a row in Guidewire, a record on the mainframe, and a party in the lakehouse, each with its own key. Until those are reconciled, a “Customer 360” query returns three disconnected fragments. Entity resolution is therefore a dedicated service, and the principal exception to virtual-first.

An enterprise graph that feeds regulatory answers and GenAI must be demonstrably correct. The raw materials exist in the ontology — SHACL shapes, DL axioms, competency questions. The strategy is to wire them into a pipeline so that quality is enforced automatically on every change.

The CI gate every change passes

The stewardship model

• Central platform team owns the foundation (fnd/), the CI harness, the federation engine and the identity service. Slow-moving, high-scrutiny.
• Domain product teams own their domain module, its mappings and its CQs — underwriting owns policy, claims owns claim. They ship on their own clock behind the shared contract.
• A change-review function guards foundation edits and cross-domain changes, because a foundation change destabilizes everyone downstream at once.

The point of the whole stack is the answers it serves. Each of the four target consumers reaches the same virtual graph through the interface that fits it — and the competency questions are the connective tissue, because a governed CQ is exactly what an application, a report and an LLM agent all want.

The delivery shape is vertical slice first, domain-product mesh later, with platform foundations built only as thin as each slice demands. Value lands in one quarter; the platform hardens under real load rather than ahead of imagined requirements.

What to measure

• Coverage — number of competency questions answerable over live data (the primary progress metric).
• Latency — p95 query response for each serving surface, and source-side load imposed by rewrites.
• Onboarding lead time — days from a new source to its first CQ answered through the graph.
• Conformance — SHACL pass rate per source, and identity precision/recall on a labeled sample.
• Adoption — consuming applications, agents and reports in production.

Principal risks & how the design absorbs them