A worked case Illustrative scenario

“If one reinsurance group failed tomorrow, what is our true exposure across every company we own?”

The board asked it on a Tuesday. It was answered eleven days later, by hand, in a spreadsheet nobody has been able to reproduce since. Not because the data was missing. Every fact needed to answer it was already sitting in systems the company owned.

Five systems each held part of the answer

Policy Administration

Knows the policy and its limits, and which legal entity wrote it.

Reinsurance Ledger

Knows the cession and the treaty — under a different policy identifier.

Entity Master

Knows the ownership tree. Three acquisitions deep in places, and six months stale.

Broker Portal

Knows the intermediated placements. Its entity codes predate the last acquisition.

Claims

Knows what actually happened, and refers to policies by a third convention.

None of them agrees on what a policy is. None of them holds both ownership trees. That is the eleven days.

Organizations spend between 40% and 60% of their IT budget reconciling meaning across systems — the cost of operating and integrating data silos that were never designed to agree.

Dave McComb, Semantic Arts — who named this problem
The work

One question, carried the whole distance

Stage 1 The need

We do not begin with your systems. We begin with what the business needs to know and cannot find out. Counterparty concentration across a group is a question the board can ask, a regulator can demand, and nobody in the organization can answer on demand — the definition of a question worth building for.

It is hard for a specific and instructive reason. Both sides of it are hierarchies. Your companies roll up through acquisitions. The reinsurer's legal entities roll up to one parent. Neither tree lives in the system that holds the exposure, so the concentration hides in the gap between them.

What you want to know comes first. The architecture follows it.

Stage 2 The competency question

The need is written down precisely enough to be tested. This is a competency question, and it becomes the specification and the acceptance criterion at the same time. Nothing gets built that does not serve it.

For a given reinsurance group, return the total ceded limit across every legal entity in that group, written by any subsidiary in ours — at any depth of ownership on either side — and flag every group above a stated concentration threshold.

Agreed and signed before a line of code is written. If we cannot answer it at the end, the engagement has not succeeded, and that is a judgment you make rather than one we get to narrate.

Stage 3 The schema

The question tells us exactly what the model must contain. Not a warehouse, not a lake — eight node types and six relationships. Everything the five systems disagreed about is resolved once, here, into a single explicit structure.

Insurance Group Subsidiary Policy Cession Broker Treaty Reinsurer Reinsurer Group PART_OF * PART_OF * WRITTEN_BY CEDED_VIA UNDER REINSURED_BY PLACED_BY * traversed to any depth — the ownership trees are not fixed, and acquisitions add edges, not columns

The two edges marked * are the ones that matter. They are recursive — walked to whatever depth the ownership happens to go. When you acquire a company next quarter, that is one new edge, not a schema migration and not a rewritten report.

Schema design is the part that cannot be delegated to a tool. It is led by Ryan Chandler, PhD — knowledge graph architect — working directly with the people who know what the words mean in your business.

Stage 4 The traversal

Answering the question is a walk through the structure — six hops, two of them to arbitrary depth. There is no reconciliation step, because the reconciling was done once, in the model.

01Start at the reinsurance group in question.
02Walk PART_OF* down to every legal entity inside it — six entities across four jurisdictions, in this case.
03Collect every treaty those entities reinsure.
04Collect every cession written under those treaties, intermediated or direct.
05Collect every policy ceded that way, and the subsidiary that wrote it.
06Walk PART_OF* up to confirm each subsidiary rolls up to our group, however deep, and sum the ceded limits.

The same six hops, written two ways. The difference is not syntax. It is that one of them has to be maintained by a person who remembers why it looks like that.

Relational Two recursive CTEs, five systems
WITH RECURSIVE ours AS (
  SELECT entity_id FROM entity_master
   WHERE entity_id = :our_group
  UNION ALL
  SELECT e.entity_id FROM entity_master e
    JOIN ours o ON e.parent_id = o.entity_id
),
theirs AS (
  SELECT re_id FROM reins_registry
   WHERE re_id = :their_group
  UNION ALL
  SELECT r.re_id FROM reins_registry r
    JOIN theirs t ON r.parent_re_id = t.re_id
)
SELECT SUM(c.ceded_limit)
  FROM policy_admin p
  JOIN ours  o  ON o.entity_id  = p.writing_entity
  JOIN policy_xref x ON x.pa_policy_no = p.policy_no
  JOIN cession   c  ON c.policy_ref  = x.rl_policy_ref
  JOIN treaty    t  ON t.treaty_id   = c.treaty_id
  JOIN theirs th ON th.re_id = t.reinsurer_id
 WHERE ...

policy_xref is the reconciliation table between three identifier conventions. It is maintained by hand. It is the eleven days, and it is wrong roughly as often as somebody forgets to update it.

Graph One pattern
MATCH (rg:ReinsurerGroup {name: $group})
      <-[:PART_OF*]-(:Reinsurer)
      <-[:REINSURED_BY]-(:Treaty)
      <-[:UNDER]-(c:Cession)
      <-[:CEDED_VIA]-(p:Policy)
      -[:WRITTEN_BY]->(:Subsidiary)
      -[:PART_OF*]->(:Group {name: $ours})
RETURN sum(c.cededLimit) AS exposure

No reconciliation, because identity was resolved once in the model rather than every time in a query. The * walks whatever depth the ownership actually has, today and after the next acquisition.

Stage 5 The validation

The graph is loaded and the competency question is put to it. It either answers correctly or it does not, and that is settled before go-live rather than discovered afterward. Every subsequent question is added to the same test and kept there.

You know it works before you go live.

Stage 6 The answer

One reinsurance group carries 31% of aggregate ceded exposure, across six of its legal entities and nine of our subsidiaries.

Two of those subsidiaries were acquired separately and had never been counted together. Eleven days became a question typed in plain language — and because the structure is explicit, the next question is answerable the same day, by anyone.

Why the answer holds

Computed, not composed

No model read those five systems and summarised them. It walked an explicit structure, and the figure above was computed by traversal.

Determinate

Ask again next quarter and the same traversal returns the same figure. It is a computation, not a composition.

Defensible

Every one of those six hops is a fact somebody asserted. Show the path, point at the record, name the system.

Documented

What a policy is, where a subsidiary boundary falls — decided once, written down, versioned, and yours.

Not a black box — a derivation you can put your name to. Why we separate computation from language →

Why it keeps paying

The next question is cheap

Nothing above was built for this question alone.

The model is single, simple, explicit and extensible, and the data and the description of the data sit in the same place. Acquire a company next quarter and that is one new edge — not a migration, not a rebuilt warehouse, not a re-cut report. Which is why an agent turned loose on this graph can follow relationships nobody anticipated and still arrive somewhere determinate, defensible, and documented. More on the data-centric approach →

Generally

The same stages in your world

It is not a migration

Everything is already digital. Moving it to the cloud moved the problem. It is not colocation but harmonization that dissolves it.

Nothing is deleted

Your systems keep running. The graph resolves what they mean, once, so that they can finally be read together.

The questions are the contract

Scope is defined as competency questions and priced as a fixed bid. Value is defined before it is delivered.

That was one question. What is yours?

Tell me what your organization needs to know and cannot currently find out. If it is a good competency question I will say so, and show you the shape of the graph that would answer it. If it is not, I will tell you that too.

Or write directly — ryan@harmonygraph.com

Thank you — it arrived.

Your question is with me.

Ryan Chandler, founder and principal architect of HarmonyGraph

Ryan Chandler, PhD

Founder and principal architect. Knowledge graphs, natural language processing, and AI systems. What gets modelled is your conceptualization of the business — your domain, your distinctions, your terms — made explicit. Your agents then behave according to that structure instead of guessing at it.

Practice
Discovery and scoping · knowledge graph implementation · conversational and agent layers
Engagements
Fixed bid wherever possible. Scope signed before work begins.
Where
211 W Wacker Drive, Chicago, Illinois