--- title: "What is a knowledge graph | Relations you can traverse | Len P. van der Hof" description: A knowledge graph stores named entities and typed relations so you can walk from one fact to another. It is not a mind map, not a vector store, and not a substitute for RAG when you need a passage. image: "https://lenvanderhof.com/media/generated/blog-hero-knowledge-graph-v1.ab5605b94c42.wide.webp" --- [AI Systems](https://lenvanderhof.com/en/blog/category/ai-systems/) Research guide # What is a knowledge graph? Named nodes, typed edges, a walk you can audit If you cannot name the edge, you have a poster. If you cannot open the node, you have a rumour. Len P. van der HofPublished 14 September 20266 min read Named cards. Labelled string. One walk under the lamp. Direct answer A knowledge graph is a store of named nodes and typed edges: this account depends on that service, this claim cites that source, this person owns that system. You query it by walking relations, not by hoping a similar paragraph appears. It is not a mind map, dashboard, or vector index. RAG fetches a passage. A graph stores how things connect. Microsoft's GraphRAG is a graph-index method for global questions across a corpus; its GitHub project is largely in maintenance mode as checked 2026-08-27. That method is not the definition of a knowledge graph. In a company the useful graphs are boring: ownership, dependencies, evidence. Keep the edge vocabulary closed and give every edge an owner and a date, or it will go stale while sounding certain. If documentation cannot answer 'what breaks if this changes,' the missing object is often an edge. ## Key takeaways - Nodes have names. Edges have types. If either is 'related,' you built a poster. - RAG answers 'show me the clause.' A graph answers 'what depends on this.' - Useful business graphs: ownership, dependencies, claim-to-source. Not a 3D hairball. - Start with a short, closed edge vocabulary. Add a verb only when a live query requires it. - An edge with no owner and no date is a confident rumour with a schema. - Documentation is a graph when a stranger can walk from a term to an owner to a changing file. 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](https://lenvanderhof.com/en/blog/what-is-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](https://lenvanderhof.com/en/blog/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](https://lenvanderhof.com/glossary/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](https://lenvanderhof.com/books/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. ## Terminology - [RAG](https://lenvanderhof.com/glossary/rag/) - [Evidence ledger](https://lenvanderhof.com/glossary/evidence-ledger/) ## Sources 1. [What is RAG?](https://lenvanderhof.com/en/blog/what-is-rag/) 2. [When to use RAG](https://lenvanderhof.com/en/blog/when-to-use-rag/) 3. [Evidence ledger (glossary)](https://lenvanderhof.com/glossary/evidence-ledger/) 4. [GRAIN (glossary)](https://lenvanderhof.com/glossary/grain/) 5. [The RAG Engineer](https://lenvanderhof.com/books/the-rag-engineer/) 6. [GraphRAG documentation](https://microsoft.github.io/graphrag/) · Microsoft 7. [Microsoft GraphRAG repository](https://github.com/microsoft/graphrag) · Microsoft ## Further reading - [What is RAG?](https://lenvanderhof.com/en/blog/what-is-rag/) - [When to use RAG](https://lenvanderhof.com/en/blog/when-to-use-rag/) - [Evidence ledger](https://lenvanderhof.com/glossary/evidence-ledger/) - [The RAG Engineer](https://lenvanderhof.com/books/the-rag-engineer/) About the author ## [Len P. van der Hof](https://lenvanderhof.com/en/authors/len-p-van-der-hof/) Entrepreneur, AI Innovator and Venture Builder Len P. van der Hof builds practical AI systems, digital ventures and evidence-informed tools for founders. ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Person", "@id": "https://lenvanderhof.com/#person", "name": "Len P. van der Hof", "alternateName": [ "Len van der Hof", "L.P. van der Hof", "Leendert Pieter van der Hof" ], "honorificSuffix": "MSc", "url": "https://lenvanderhof.com/", "image": [ "https://lenvanderhof.com/photos/len-portrait-1.jpg", "https://lenvanderhof.com/photos/len-portrait-2.jpg", "https://lenvanderhof.com/photos/len-portrait-3.jpg", "https://lenvanderhof.com/photos/len-portrait-4.jpg", "https://lenvanderhof.com/photos/len-speaking.jpg", "https://lenvanderhof.com/photos/len-hero.jpg" ], "jobTitle": "Entrepreneur, AI Innovator and Venture Builder", "description": "Len P. van der Hof is a Dutch entrepreneur and AI innovator building ReasonKit, MindSesh, Undominated.ai, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures.", "address": { "@type": "PostalAddress", "addressLocality": "Zwijndrecht", "addressCountry": "NL" }, "alumniOf": { "@type": "CollegeOrUniversity", "name": "Rotterdam School of Management, Erasmus University" }, "knowsAbout": [ "Artificial intelligence", "AI agents", "Agentic AI systems", "LLM routing", "SEO", "Generative engine optimization", "Answer engine optimization", "Venture building", "Founder performance", "Founder psychology", "Evidence-based decision-making" ], "sameAs": [ "https://www.linkedin.com/in/lenvanderhof/", "https://x.com/LenvanderHof", "https://www.youtube.com/channel/UCTG20buKqYYbitqqf7l3zJA", "https://www.instagram.com/Lenvanderhof/", "https://www.threads.com/@lenvanderhof", "https://github.com/Lenvanderhof", "https://huggingface.co/LPH98", "https://www.npmjs.com/~lenvanderhof", "https://www.goodreads.com/author/show/70983905.Len_P_van_der_Hof", "https://www.amazon.com/author/lenvanderhof", "https://www.bol.com/nl/nl/b/len-p-van-der-hof-msc/609879394/", "https://bsky.app/profile/lenvanderhof.com", "https://mastodon.social/@Lenvanderhof", "https://crates.io/users/Lenvanderhof", "https://cursor.com/@Lenvanderhof", "https://medium.com/@Lenvanderhof", "https://gitlab.com/Lenvanderhof", "https://hub.docker.com/u/lenvanderhof/", "https://dev.to/lenvanderhof", "https://www.facebook.com/Lenvanderhof", "https://soundcloud.com/Lenvanderhof" ], "affiliation": [ { "@id": "https://lenvanderhof.com/#publisher" }, { "@id": "https://lenvanderhof.com/#mindsesh" }, { "@id": "https://lenvanderhof.com/#lifestyle" } ] }, { "@type": "WebSite", "@id": "https://lenvanderhof.com/#website", "url": "https://lenvanderhof.com/", "name": "Len P. van der Hof", "description": "Len P. van der Hof is a Dutch entrepreneur and AI innovator building ReasonKit, MindSesh, Undominated.ai, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures.", "inLanguage": [ "en", "nl" ], "publisher": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#publisher", "name": "LPH98.ventures", "url": "https://lph98.ventures", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#mindsesh", "name": "MindSesh", "url": "https://mindsesh.net", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#reasonkit", "name": "ReasonKit", "url": "https://reasonkit.sh", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#undominated", "name": "Undominated.ai", "url": "https://undominated.ai", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#lifestyle", "name": "LPH98.lifestyle", "url": "https://lph98.lifestyle", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "ImageObject", "@id": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/#primaryimage", "url": "https://lenvanderhof.com/media/generated/blog-hero-knowledge-graph-v1.ab5605b94c42.wide.webp", "contentUrl": "https://lenvanderhof.com/media/generated/blog-hero-knowledge-graph-v1.ab5605b94c42.wide.webp", "representativeOfPage": true }, { "@type": "BreadcrumbList", "@id": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://lenvanderhof.com/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://lenvanderhof.com/en/blog/" }, { "@type": "ListItem", "position": 3, "name": "AI Systems", "item": "https://lenvanderhof.com/en/blog/category/ai-systems/" }, { "@type": "ListItem", "position": 4, "name": "What is a knowledge graph? Named nodes, typed edges, a walk you can audit", "item": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/" } ] }, { "@type": "WebPage", "@id": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/#webpage", "url": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/", "name": "What is a knowledge graph? Named nodes, typed edges, a walk you can audit", "description": "A knowledge graph stores named entities and typed relations so you can walk from one fact to another. It is not a mind map, not a vector store, and not a substitute for RAG when you need a passage.", "isPartOf": { "@id": "https://lenvanderhof.com/#website" }, "primaryImageOfPage": { "@id": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/#primaryimage" }, "breadcrumb": { "@id": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/#breadcrumb" }, "inLanguage": "en-GB" }, { "@type": "BlogPosting", "@id": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/#article", "mainEntityOfPage": { "@id": "https://lenvanderhof.com/en/blog/what-is-a-knowledge-graph/#webpage" }, "headline": "What is a knowledge graph? Named nodes, typed edges, a walk you can audit", "description": "A knowledge graph stores named entities and typed relations so you can walk from one fact to another. It is not a mind map, not a vector store, and not a substitute for RAG when you need a passage.", "datePublished": "2026-09-14T07:00:00.000Z", "author": { "@id": "https://lenvanderhof.com/#person" }, "publisher": { "@id": "https://lenvanderhof.com/#person" }, "image": [ "https://lenvanderhof.com/media/generated/blog-hero-knowledge-graph-v1.ab5605b94c42.square.webp", "https://lenvanderhof.com/media/generated/blog-hero-knowledge-graph-v1.ab5605b94c42.landscape.webp", "https://lenvanderhof.com/media/generated/blog-hero-knowledge-graph-v1.ab5605b94c42.wide.webp" ], "articleSection": "AI Systems", "inLanguage": "en-GB" } ] } ```