What it looks like once it’s built.

Not a warehouse, not a lake — a layer of meaning

Ask what an enterprise knowledge graph is, once built, and the honest answer is a shift in kind, not size. A warehouse copies data into one place and imposes one schema. A lake pools it and defers the schema. A knowledge graph does something different: it leaves the data where it lives and adds a shared, machine-interpretable layer of meaning on top — so that a policy in one system, a claimant in another, and a coverage code in a third are understood as the same concepts, connected, wherever they physically sit.

Concretely, a built graph turns your enterprise into one navigable web of typed things. A policyholder is a single node with a https://data.chubb.com/resource/… identity, reachable from every policy they hold, every claim they filed, and every submission they made — across business units that have never shared a database. The value is not that the data is collected; it is that the data is connected and understood.

This brief has two halves. First, the anatomy — the layers and artifacts you would actually find in a built graph. Then the use cases — four families of what an organisation does with it, each grounded in insurance. For how to build each layer and the roadmap to get there, its companion is the virtual-first strategy brief; this one is the destination that brief is a route to.

Open up a mature enterprise knowledge graph and you find the same layers, whatever the vendor. Data stays at the bottom in the systems that own it; meaning lives in the middle; consumers reach it through purpose-fit doors at the top; and a governance spine runs through all of it.

The middle band — the semantic core — is the graph proper. Everything below it exists to feed it; everything above it exists to consume it. Here is what each artifact does:

The through-line: every prior brief in this series is a part of this picture — RDFS/OWL for the meaning, SHACL for the trust, SKOS for the reference data, R2RML for the bridges, stable IRIs for identity. A built graph is those decisions, assembled and running.

A graph earns its keep through applications, and they fall into four families — each leaning on a different strength of the built graph. Integrate exploits global identity; discover exploits connected meaning; reason & detect exploits the graph structure and inference; govern exploits provenance and formal definitions.

The families are not equally demanding. Some ride on identity alone; others need the reasoner, the vector index, or the provenance spine. Reading the graph this way tells you what to build first for the use case you care about.

Read it as: ●●● the load-bearing capability for that family, ○ barely used. A 360 view is mostly an identity problem; a grounded assistant is mostly a search-and-meaning problem; fraud and exposure are reasoning problems; compliance is a provenance problem.

Watch the anatomy deliver a use case. An underwriter asks a question no single system can answer:

What is our total hurricane exposure to the Acme corporate group — across every subsidiary and policy in the coastal counties — and are any related claims still open?

• Identity resolves “the Acme group” to its subsidiaries, reconciled from three source systems into one ownership tree.
• The ontology knows a Policy has Coverage with a Limit, and that wind is a Peril in a governed SKOS scheme — so “hurricane exposure” is a precise query, not a guess.
• Mappings pull the live policy and claim rows from the systems that own them; nothing had to be copied in advance.
• Reasoning & traversal walk ownership → policy → coverage → location, sum the limits in the coastal counties, and follow party links to any open claims.
• Provenance tags every number with its source, so the underwriter — and later an auditor — can see exactly how the total was built.

# Sketch: exposure roll-up over the connected graph
SELECT (SUM(?limit) AS ?exposure) WHERE {
  ex:AcmeGroup org:hasSubsidiary* ?org .            # identity: the whole group
  ?policy agr:hasPartyInRole/agr:party ?org ;
          coverage:hasCoverage ?cov .
  ?cov coverage:againstPeril skos:broaderTransitive* peril:Wind ;  # meaning: hurricane = wind peril
       coverage:hasLimit ?limit ; core:atLocation ?loc .
  ?loc core:inCounty ?county . FILTER(?county IN (:coastal)) # accumulation by place
}

The last thing to say about a built enterprise knowledge graph is that it is never quite finished. It starts as a thin slice — one domain, a handful of sources, a first 360 view — and grows outward as each new source is mapped and each new question is asked. Because meaning is modular and identity is global, the graph you have keeps compounding in value: every entity you connect makes the next connection more useful. A warehouse is done when it is loaded; a knowledge graph is alive as long as the enterprise is.

We are drowning in information but starved for knowledge. John Naisbitt, Megatrends

The enterprise already has the information — scattered across the systems it has run for decades. A knowledge graph is what turns that information into knowledge: connected, understood, and finally able to answer the questions the business has always wanted to ask.