What is a knowledge graph? Named nodes, typed edges, a walk you can audit

A knowledge graph is a store of named nodes and typed edges. A node is a thing you can point at: a person, a system, a contract, a claim. An edge is a labelled relation: owns, depends-on, cites, supersedes, is-bound-by. You query it by walking. Who owns this service. What breaks if we change it. Which source backs this sentence.

If the edge is unlabelled “related,” you have a poster. If the node has no name a stranger can look up, you have a rumour with nicer layout.

Not a mind map, not a vector store, not RAG

A mind map is a drawing. It does not answer a query twice the same way.

A vector store retrieves similar text. Similarity is not a type. “Close in embedding space” is not “depends-on.”

RAG fetches a passage, then writes. Use it when the job is “open clause 12.3.” A knowledge graph answers “what is connected, and how.” You often want both. You should not use one word for both jobs. When to use RAG is the retrieval-choice page. This page is the relation-choice page.

Microsoft’s GraphRAG extracts entities and relations from a corpus, detects communities, and generates community summaries for global questions across that corpus. Its public GitHub README, read 2026-08-27, says the project is largely in maintenance mode. It is one way to build a graph index from prose and feed a language model; it is not the definition. A sales-ops graph of accounts, owners, and products can exist with no LLM at all. If the graph exists only inside retrieval, call it a graph index. Institutional memory also needs owners, dates, and operational queries.

How it sits next to AI

Language models are fluent. They are not a register. If you ask “who owns billing” and the answer cannot name a node with an owner edge, you got a paragraph. Tomorrow the paragraph will drift.

Useful pattern:

1. Keep the graph as the register: nodes, typed edges, a timestamp, a source.
2. Let retrieval fetch the passage that justifies an edge when the edge is disputed.
3. Let the model draft from those two, not from folklore.

The evidence ledger on this site is already a graph in boring clothes: claim, source, strength, what would retire it. Operators use it so a number cannot wander between chapters. That is knowledge-graph work without a hairball visualisation.

Where it earns its keep in a company

Skip the 3D demo. Three graphs pay rent.

Ownership. System, document, metric, customer record: who is the named owner. Not a team name. A person who can fail a change.

Dependencies. What this launch, this service, this clause depends on. “What breaks if we change this” is a walk, not a standup guess.

Evidence. Claim to source. Decision to the note written before the act. Forecast to the bet you would actually place.

Entrepreneurship is full of missing edges. A pitch says the market is adjacent. Adjacent is not a type. A hire is “in the network.” Network is not an edge. Write introduced-by or stop pretending you have a map.

Walk one: what breaks if we turn this off

An engineer proposes deprecating an old pricing service. The room does what rooms do: three people say “I think marketing still calls it,” nobody is sure, and the decision is deferred for two weeks so somebody can ask around.

With a graph, that is a query rather than a memory test.

1. Start at the node pricing-service-v1. Walk every incoming depends-on edge. You get the checkout flow, a quote generator nobody has touched in a year, and a nightly export.
2. From each of those, walk owned-by. You get three names, not three team labels. One of them left in June, which is its own finding: that node has no current owner and the deprecation now needs an ownership repair.
3. From the nightly export, walk feeds. It lands in the revenue dashboard the board reads on Monday. That edge is why this is not a two-week deferral. It is a sequencing problem with a fixed date.

Three hops, three real answers: who has to agree, what silently breaks, and what has no owner at all. The graph did not make the decision. It replaced “I think marketing still calls it” with a list you can act on.

If your answer to step one is “we would have to grep the codebase and ask in Slack,” that is the honest state of your register. Grep finds callers in code. It does not find the analyst with a saved query, the Zapier automation, or the contract clause that promised the endpoint stays up.

Keep it small enough to stay true

Two disciplines separate a graph that pays rent from one that becomes a second wiki nobody trusts.

Close the vocabulary. Start with the edge types required by one live workflow: perhaps owns, depends-on, feeds, cites, supersedes, and governed-by. Add a verb only when a real query cannot be expressed without it. If owns, responsible-for, is-steward-of, and accountable-for mean the same thing in one store, queries split the truth across synonyms. A closed list is what makes the walk possible.

Date every edge and give it an owner. Prose ages visibly; people can hear that a doc is from 2024. A graph ages invisibly. owned-by: Marta looks exactly as authoritative six months after Marta changed teams. Every edge carries who asserted it and when. Anything past its review date gets shown as stale rather than quietly served as current. An edge nobody will re-confirm is a rumour with a schema.

Documentation that a stranger can walk

Docs fail when they are a pile of pages with no typed links. A useful documentation graph is small.

• Every important term is a node with one owner.
• Every runbook names the system it governs and the file that would change.
• A cross-link states its relation; “see also” is not a useful edge type.
• When a page dies, incoming edges show what you just orphaned.

If a new operator cannot go from “refunds” to the policy file to the person who may change it in three hops, the wiki is a blog. RAG over that wiki can retrieve a fluent wrong page. A current supersedes edge would make the stale page visible before it entered the answer.

A five-minute fail test

Pick one decision from last week.

1. Name the nodes involved. If you cannot, you do not have entities. You have a story.
2. Name the edges. If the verb is “related,” rewrite it or delete it.
3. Point at a source for each edge. A meeting that nobody wrote down is not a source.
4. Ask what breaks if one node is wrong. If the answer is “nothing visible,” the graph is decorative.
5. Trace the answer back to graph records. If you cannot, you shipped prose, not a query result.

You do not need a new database to start. A table with five columns (from, type, to, source, asserted-on) is enough. Cover one high-stakes workflow end to end: its load-bearing systems, current owners, and dependencies. The visualisation can wait. The typed edge cannot.

The RAG Engineer is the longer retrieval practice. It is available now. You do not need it to refuse a slide that says “we have a knowledge graph” and cannot name a single edge.