Knowledge graphs for professional services firms: a plain explanation

Most explanations of knowledge graphs begin with triples, ontologies and a diagram of nodes and edges, and lose the reader who actually needed to know something. This one begins with the questions, because the case for a graph is entirely in the shape of the questions firms ask.

Look at what the questions have in common

Three ordinary requests, from three ordinary situations in a firm:

• Who here has a relationship with the finance director at this client?
• Have we delivered anything like this before, and who ran it?
• What does this client need that we have never sold them?

Now look at what answering each one requires. Not the information, the traversal.

The first goes from a client-side person, to the engagements they were involved in, to the colleagues who delivered those engagements. Three hops.

The second goes from a type of work, to the engagements that evidence it, to the people who led them, and often on to whether those people are still at the firm. Three or four hops.

The third goes from a client, to the capabilities their own material shows they need, and compares that set against the capabilities the firm has evidence of delivering for them. It requires holding two sets against each other and looking at the difference.

Every question a firm asks about its own work is a question about relationships between things, not about the things themselves.

That is the whole argument. A structure that stores documents can answer "find me things that mention X". A structure that stores relationships can answer "get from this person to the people who know them", which is a different kind of question and the one that actually arises.

What a graph is, in this specific case

Set aside the general theory. In a firm, the graph has four kinds of node and a small number of link types.

The nodes

• Colleagues. People at the firm.
• Stakeholders. People at the client.
• Engagements. Discrete pieces of work the firm has delivered.
• Capabilities. The general things the firm can do, as evidenced by engagements.

The links

• A colleague delivered an engagement, in a particular role.
• A stakeholder was involved in an engagement, in a particular role.
• An engagement evidences a capability.
• A client needs a capability, on the evidence of their own material.

That is close to the entire model, and its smallness is the point. Four node types and four link types are enough to answer all three questions above, plus most of the others firms actually ask.

The property that makes it usable: every link carries its source

A graph of assertions is a liability. If the atlas says a colleague led an engagement, the natural question from anyone about to act on it is how it knows, and if there is no answer the fact cannot be used for anything that matters.

So in OrgAtlas every link carries the document or thread behind it. The relationship between a colleague and an engagement is not a bare edge, it names what the relationship is and points at the proposal, report or thread that establishes it.

This changes what the graph is for. It is not a summary of the firm to be consulted and believed. It is an index into the evidence, and the evidence remains available at every point. A partner who does not accept a claim opens the thing behind it and settles the question in one click, or corrects it in two.

The same property makes multi-hop answers auditable. Trace a path from a partner to a stakeholder through two engagements and every step of that path names the document it stands on. The answer is not "the system says these people are connected". It is a chain of specific, checkable facts.

What the weight on each item means

There is one more piece, and it is the part firms find most immediately useful.

Not all evidence is equal. A colleague who led four engagements in a domain and a colleague who was copied on one both have a link to that capability. Treating those identically produces the same failure as a self-reported capability database: a search returns forty names and discriminates nothing.

So each item carries a weight, which is how much proven evidence stands behind it, and that weight sets the running order. Nobody adjudicates. Nobody ranks themselves against a colleague. The evidence does it.

The corollary matters more. A capability with nothing behind it is drawn hollow rather than omitted, which is how the third question becomes answerable. A gap you can see is an opportunity. A gap that was simply left out of the data is invisible.

A record that only contains what the firm has done cannot show what it has not.

What this is not

Three clarifications, because this category attracts overstatement.

It is not a chatbot with a graph attached. The interface is a chart you navigate, not a dialogue box that returns prose. You can ask it questions, and what comes back is items and links you can open, not a paragraph you have to take on trust.

It is not an ontology project. Firms that have been through enterprise knowledge programmes are right to be wary here: the classic failure is eighteen months designing a taxonomy that nobody then populates. Four node types is deliberately close to the minimum that answers the questions.

It is not a replacement for the document store. The documents stay where they are and remain the authority. The graph is an index over them, and its value is that it indexes by person and by capability rather than by folder.

Why this is the right structure for the next decade

One forward-looking reason, briefly.

Whatever a firm does with AI over the next few years, every system it buys will need to be told what the firm knows. A model pointed at an undifferentiated document store can tell you which files mention a topic; it cannot tell you which partner genuinely led that work, because nothing in the store records it.

A graph where every relationship carries its source is a substrate that survives model generations. It is useful to a person navigating it today, and it is the thing you point an agent at tomorrow so that its answers can be checked rather than merely believed.

Next: GraphRAG against vector search, on the specific question of who knows this client