How to Build a Personal Knowledge Graph (Founder's Guide)

A personal knowledge graph is a structured representation of what you know: the entities in your professional world - companies, people, metrics, products, decisions - and the relationships between them. It is different from a folder of documents in the same way a map is different from a pile of photographs of streets.

The practical payoff is that a graph can answer questions no single document contains. 'What changed about our retention story between the seed deck and now?' requires connecting two documents written eight months apart. A search index cannot do that. A graph can.

Why folders fail

Your knowledge is currently distributed across a deck in Google Slides, metrics in a spreadsheet, decisions in Notion, context in Slack threads, and the largest share of it in your head. Every one of those stores is disconnected from the others, and the connections are the valuable part.

This is why 'just upload everything' produces a disappointing result. Volume without structure gives you a chatbot that quotes the wrong version of a number with total confidence.

The ten documents to start with

You do not need a hundred documents. You need the ten that carry the most connective tissue. In rough priority order:

Your current pitch deck. Highest density of entities and claims per page.
A metrics snapshot with dates. Dates matter more than precision - they let the graph resolve which figure is current.
The most recent investor update. Captures trajectory, not just state.
A one-page company narrative. Why this, why now, why you.
Product documentation or a technical overview. What it actually does.
Two or three customer case studies. Concrete beats abstract for grounding.
Your own bio and CV. The twin needs to know who it is representing.
A competitive landscape note. Where you sit and why.
An FAQ of questions you already answer constantly. Direct automation targets.
A short 'what I am looking for' memo. Hires, intros, partners, capital.

Four rules that determine quality

Date everything

An undated metric is worse than a missing one, because the graph cannot tell whether it is superseded. Put the as-of date in the document body, not just the filename.

Name entities consistently

If a customer is 'Acme' in one document, 'Acme Corp' in another and 'the logistics client' in a third, you have created three entities where there is one. Consistency in naming is the single cheapest thing you can do to improve answer quality.

Write the caveats down

The context that lives only in your head is usually a qualification: this number excludes one anomalous month, that logo is a pilot not a contract. Uploaded without its caveat, a fact becomes a liability. Write a two-line note next to anything you would verbally qualify.

Prefer substance over polish

A rough internal memo grounds better than a designed brochure, because marketing copy is optimised to avoid specifics and grounding rewards exactly the specifics it removed.

Testing whether it worked

Write down five questions you can already answer perfectly, ideally ones with a subtlety a naive reader would get wrong. Ask the twin. You are not checking whether the answers sound good - fluent wrong answers are the failure mode. You are checking whether the citations point at the right source and whether the caveats survived.

Where an answer is thin, you have found a gap in the graph rather than a limitation of the system. Fix it with a document, not a prompt.

Maintenance is the whole game

A graph decays at the speed your company changes, which for an early-stage startup is fast. Fifteen minutes a month - drop in the latest update, refresh the metrics snapshot, add anything you found yourself explaining repeatedly - keeps it current.

That habit compounds in a way that is easy to miss. A year in, you have a structured, queryable record of every decision and number in the business, which turns out to be useful far beyond networking: diligence, onboarding, board prep and your own memory all draw on the same asset.