“Which clients buy one service when they could buy five — and who here already has the relationship?”

We do not begin with your systems. We begin with what the business needs to know and cannot find out. Where the unworked revenue already is — in accounts that already trust you — is the cheapest growth a firm has, and almost nobody can name it on demand.

It is hard for a specific and instructive reason. Both sides of it are hierarchies. Your clients roll up — divisions, subsidiaries, a parent that buys under its own name. Your services roll up too — offerings inside service lines inside practices. Neither tree lives in the system that records the revenue, so the gap hides between them.

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

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.

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.

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

The two edges marked * are the ones that matter. They are recursive — walked to whatever depth the ownership and the taxonomy happen to go. Reorganise the practices next year and that is new edges, not a rebuilt 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.

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.

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.

WITH RECURSIVE grp AS (
  SELECT org_id FROM crm_account
   WHERE org_id = :client_group
  UNION ALL
  SELECT a.org_id FROM crm_account a
    JOIN grp g ON a.parent_org_id = g.org_id
),
svc AS (
  SELECT svc_id, parent_svc_id FROM service_cat
  UNION ALL
  SELECT s.svc_id, s.parent_svc_id FROM service_cat s
    JOIN svc x ON s.parent_svc_id = x.svc_id
)
SELECT DISTINCT sl.line_name, p.person_name
  FROM grp g
  JOIN client_xref cx ON cx.crm_org_id = g.org_id
  JOIN billing_matter m ON m.client_code = cx.billing_code
  JOIN delivery_eng   e ON e.matter_ref  = m.matter_ref
  JOIN svc            s ON s.svc_id      = e.service_id
  JOIN service_line  sl ON sl.line_id    = s.root_line_id
  JOIN eng_staffing  st ON st.eng_id     = e.eng_id
  JOIN directory      p ON p.person_id   = st.person_id
 WHERE ...

MATCH (g:ClientGroup {name: $group})
      <-[:PART_OF*]-(o:ClientOrg)
      <-[:FOR]-(e:Engagement)
      -[:DELIVERED]->(:Service)
      -[:PART_OF*]->(line:ServiceLine)
MATCH (p:Person)-[:LED]->(e)
RETURN collect(DISTINCT line.name) AS bought,
       collect(DISTINCT p.name)    AS whoKnowsThem

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.