Explainers · entities, edges, and your codebase · 8 min
What is a knowledge graph? Google draws one for the web. Your code has one too.
Google an actor and a tidy panel appears: films, co-stars, birthday. You never searched those facts one by one; something already knew how they connect. That panel is a knowledge graph, and Google made the idea a household word in 2012 under a three-word banner: things, not strings. Your machine is full of the same hidden structure: files that ship together, repos that share code, the document you always open beside one spreadsheet.
Nobody ever draws that map for your code. On a real 4.47-million-file machine, Interlinked drew 26,958 of those connections in 1.7 seconds (on the day it was installed, before a single search) and noticed two repositories quietly sharing 435 identical files that no one had told it were related.
The definition
Entities, and how they connect.
A knowledge graph is a way of storing information as entities (the real things in a domain) joined by typed relationships that state how those things relate. Instead of rows sitting in isolated tables, the connections themselves become first-class data: this imports that, these two change together, this repo contains that file. The idea is older than Google (semantic networks and the Semantic Web were drawing typed graphs of "things" for decades), but Google made it a household word when it launched its Knowledge Graph in 2012.
Map it onto a machine and the translation is exact. The entities are your files, folders, repositories, functions, and symbols. The relationships are things like imports, references, belongs-to, changes-with, and shares-files-with. A code index tells you a file exists; a code knowledge graph tells you what it is attached to.
The definition. A knowledge graph stores information as entities (the real things in a domain) joined by typed relationships that state how those things relate. Google made the term famous in 2012 under a three-word banner: things, not strings.
For your code. The entities are your files, folders, and repos; the relationships are imports, references, files that change together, and repos that share code.
Two kinds of edge. Some edges are written in the code (imports, folder membership). The valuable ones are derived from behavior (files co-changed 6×, repos sharing 435 identical files), edges no single-repo tool can see.
Receipts, not guesses. Every edge is a countable fact (a shared commit, a matching content hash), checkable by hand. No model, no embeddings, nothing that can invent a connection.
Built automatically. On a real machine, Interlinked drew 26,958 relationships from 8,455 git events in 1.7 seconds (on install day, before the first search) and caught two repos quietly sharing 435 identical files.
The payoff is that questions no editor can answer become one hop away: what moves with this file? which repos overlap? what is really connected to what I just touched?
The graph, drawn
Nodes are your files. Edges are how they relate.
Two repositories, three files, five relationships. The gray edges are written into the code: checkout.tsx imports a button; each file belongs to a repo. Any editor can see those. The blue edges are the ones that matter and the ones nobody types: two files that keep changing together, and two repos that turn out to share hundreds of identical files. Those cross repo boundaries, which is exactly why a tool that only reads one project at a time can never draw them.
The blue co-change · 6× edge is the one that pays off: when an agent opens checkout.tsx, the graph already knows cart.tsx is the file it will need next: no reference in the code says so, six commits of history do.
The vocabulary of a code graph
Five relationships. Two you can see, three you can't.
Every edge in the graph is one of a small number of types, and each is built from a plain, checkable fact. Never a model's guess. The top two are visible to any editor. The bottom three are the moat: they only appear when something watches the whole machine at once.
| Relationship (edge) | What it means | The receipt it's built from |
|---|---|---|
| Written in the code: any editor can see these | ||
| belongs-to | a file lives inside this folder or repo | its path on disk |
| imports / references | this file uses that one | the literal line in the code |
| Derived from behavior: only a whole-machine graph sees these | ||
| changes-with | two files keep getting saved in the same commit | a count from git history, e.g. co-changed 6× |
| shares-files-with | two repos hold byte-for-byte identical files | matching content hashes, e.g. 435 identical |
| named-in | one project's name or symbol appears inside another | a count of the files that literally reference it |
Every edge names its own count, so a wrong conclusion is visibly wrong: you can open the git log or grep the string and check it in one step. The derived-from-behavior idea is old science (researchers proved in the 1990s that files changing together are coupled in reality); running it live, machine-wide, across every repo is the new part. More on how each edge is derived in files that find each other.
Receipts, not guesses
Every edge is a fact you can check. None of them are a model's hunch.
This is the line that separates a code knowledge graph from the AI-flavored alternatives. An embedding tells you two files are probably related; a vector database and RAG trade in likelihood and can be confidently wrong. This graph does not do "probably." Every edge is a fact the operating system already recorded (a shared commit, a matching content hash, a literal reference) turned into a count and checked against a floor. It is not RAG and it is not memory; it is the checkable layer underneath both.
Because the edges are keyed to each file's identity in the operating system, they survive a rename or a move: the connection does not break when you tidy up. And because they cross repo boundaries, the graph can state a thing no in-repo tool can: that a folder of "separate" projects is really a collection of repos that ship together.
Prior art · 2012 to now
Google mapped the web. Sourcegraph maps your pushed code. This maps your machine.
A knowledge graph has always been a server-side thing. Google's Knowledge Graph webs billions of public entities behind its search box. Sourcegraph and Glean brought the pattern inside the company: a code graph, or a work graph, assembled on a server from the repositories and documents you send them. All of it real, all of it useful, all of it living somewhere other than your machine and seeing only what has been pushed.
Interlinked runs the same idea in the one place it never runs: the disk in front of you, offline. It saw that two local repos share 435 identical files (one is the other's ancestor), unpushed, unconfigured, on day one, across every repo and the ~90% of the drive that was never in git. Same 2012 idea, run the way nobody else runs it: in a free tool, on your machine, with nothing leaving it. The scoping tradeoffs are laid out in Sourcegraph vs local search.
A knowledge graph for the whole machine
You don't build this graph. It draws itself, and rides along.
There is nothing to configure and nothing to feed it. The first time Interlinked runs, it reads the deepest history already on the machine (your git commits) and webs the whole thing together. From then on the graph grows from what you actually do, and it arrives where it is useful: an edge rides along underneath a search the agent was already going to run, so the next file names itself before the agent thinks to look. Speed finds the file; the graph knows why it matters.
The same engine that answers a filename lookup in 85 microseconds (412,000× faster than VS Code's 35-second search, the difference between a wait and a blink) carries this graph beside it, offline, on the machine, belonging to no vendor. It is the memory half of the fast floor every agent stands on, the larger story in the backbone of the LLM economy.
THE GRAPH IS THE MOAT: RECEIPTS, ACROSS EVERY REPO, ON YOUR MACHINE, OFFLINE.
Questions people ask
Knowledge graphs, answered.
What is a knowledge graph, in one sentence?
It is a way of storing information as entities (real things like files, repos, or people) connected by typed relationships that say how those things relate, so the connections themselves are data you can query, not something you have to reconstruct every time.
What is the difference between a knowledge graph and a database?
A plain database stores rows in separate tables and you re-derive relationships with joins at query time. A knowledge graph makes the relationships first-class and stored, so "what connects to this?" is a direct, cheap question. For code that matters, because the useful facts (which files move together, which repos overlap) are relationships.
Is a code knowledge graph the same as Sourcegraph's code graph?
Same idea, different scope. Sourcegraph builds a code graph on a server from the repositories you push to it. Interlinked's graph is live and on your own machine, spanning every repo and the ~90% of the disk that was never in git. Offline, no server. See Sourcegraph vs local search.
Does the graph use AI, embeddings, or a model?
No. Every edge is a receipt (a count of shared commits, a matching content hash, a literal reference) that you can verify by hand in one step. That is the difference from a vector database or RAG, which return things that are probably similar. A receipt is either true or it is visibly wrong.
How does the graph stay current as I work?
It rides the same live index that answers searches: save a file and it is re-indexed in about a millisecond. New relationships form as you go (the files you keep saving together, the documents you open in one sitting), so the graph is never more than a moment behind what is actually on disk.
Draw the graph on your own machine
Install it tonight. It knows how your repos connect by morning.
Install once. One signed installer wires up 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest. No JSON to edit.
Let it read the history. On day one it seeds the graph from your git commits: every repo on the disk, webbed from its own past, in seconds.
Just work. New edges form from what you actually do: the files you save together, the documents you open in one sitting. Nothing to tag, nothing to feed it.
Let your agent read it. Ask “what repos do I have?” and you get biographies, not a directory listing. And the next file names itself on the searches the agent already runs.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · Next: the machine gets biographies