Core Concepts
How OpenKnowledge works: the three-layer model, the file system as the database, links and backlinks, the well-connected knowledge base, and attribution.
This page is the precise reference for the ideas the rest of the docs build on. If you want the persuasive tour instead, start with the Overview; if you want to start using it, see the Quickstart.
Three layers
OpenKnowledge has three layers working together:
- a surface you edit
- an engine that keeps it consistent
- the files underneath
All three layers operate on the same files. You can edit through the editor, an agent can edit through the knowledge engine's MCP tools, and you can always drop down to any text editor and change the markdown by hand. Nothing locks you out.
Because the knowledge engine is exposed over MCP, it is agent-agnostic. Bring Claude Code, Cursor, Codex, OpenCode, OpenClaw, or any MCP-capable client, and any model you have access to.
The file system is the database
The third layer is the content itself. OpenKnowledge has no database dependency. Your knowledge base is plain markdown files in your own project directory, and the only persistence layer is the file system, version-controlled by git.
This means:
- No lock-in. Your knowledge is portable markdown you can read, grep, diff, and commit with ordinary tools.
- Almost nothing to install. The recommended path is the desktop app (macOS 13 or later, Windows, or Linux); there is no separate database or service to run.
- The engine is a management layer, not a gatekeeper. It maintains consistency when you go through it, but editing the raw files yourself is always allowed.
The set of files the engine treats as your knowledge base is the configured content directory. See Configuration for where that and other settings live.
Links and backlinks
Internal cross-references are written with standard markdown links. The recommended form is relative — [text](./sibling.md), [text](../folder/doc.md) — which stays portable across GitHub, Obsidian, VS Code, and published sites. A root-absolute form ([text](/folder/doc.md), where the leading slash means the content root) is equally valid and convenient for cross-folder links. The two never mix: never glue ./ onto a content-root path, since ./folder/doc.md written from a doc already inside folder/ resolves to the doubled, broken folder/folder/doc.md — write/edit flag exactly this in their brokenLinks response. Whenever document A links to document B, OpenKnowledge automatically records the inverse on B: a backlink from B back to A.
Review links after upgrading
A wiki link such as [[notes/beta.md]] first checks for a document whose path is exactly notes/beta.md. If none exists, OpenKnowledge removes one terminal .md or .mdx (case-insensitive) and resolves notes/beta. It does not repeatedly remove suffixes: [[notes/beta.md.md]] can fall back to notes/beta.md, but not notes/beta. If the suffix-free name finds no document, resolution tries the original spelling.
After the original exact-path check, OpenKnowledge fully resolves the suffix-stripped spelling: exact path, case- and punctuation-insensitive slug, folder index page (or its same-named page), then matching basename when the link has no slash. Only if that finds nothing does it try the original spelling's fuzzy, folder-index, and basename fallbacks. Without a Markdown suffix, those checks run once on the original spelling. If multiple paths have the same fuzzy slug or basename, the path smallest in UTF-16 code-unit order wins. For example, with reports/index.md and reports-md.md, [[reports.md]] opens reports/index before trying the fuzzy match for reports-md. An exact, case-matching path avoids a fuzzy tie.
Every exact-path check, in every link form except wiki asset links and embeds (see below), compares names with one identity rule. Document and folder names match case-sensitively. File names (images, PDFs, and other non-markdown files) match case-insensitively. Names that differ only in Unicode normalization are the same name for every kind: é stored as one character (NFC) or as e plus a combining accent (NFD) matches either spelling, so a link typed on Linux opens a file whose name macOS stored decomposed. Characters that only compatibility normalization would merge, such as the fi ligature and fi, stay distinct. When two stored names are equivalent, an exact spelling wins; otherwise the name smallest in UTF-16 code-unit order wins.
Markdown and wiki asset links treat folder case differently. A Markdown asset link such as  matches each parent folder case-sensitively and only the file name case-insensitively, so it no longer finds images/cat.png. A wiki embed such as ![[Images/cat.png]] still matches its whole path case-insensitively. On macOS and Windows, whose file systems ignore case, a Markdown asset link whose folder case differs from the folder on disk can show as broken after upgrading; correct the folder spelling in the link.
After upgrading, review existing wiki links and shorthand targets that omit a folder, differ only by case or punctuation, or end in .md or .mdx. Open each link or use the MCP links tool with kind: "forward" to inspect its resolved destination. If a valid link now opens a different document, replace its target with the intended document's exact path. Use audit to find broken links, but do not rely on it to detect a link that still resolves to the wrong document. For new cross-document links, prefer the explicit relative or root-absolute Markdown paths above.
You never write backlinks by hand. They are computed from the links you already write, and together they form the link graph: the network of relationships across your knowledge base.
The well-connected knowledge base
"Well-connected" is not a vibe; it has concrete substance:
A well-connected knowledge base = backlinks + the link-graph tools (dead / orphans / hubs / suggest) + closed-loop grounding.
An agent puts all three to work when it retrieves: it searches, greps, and follows backlinks in a loop over your live files, with no vector database. That mechanism is Agentic search.
Backlinks
The automatic inverse relationships described above. They turn a pile of files into a navigable graph.
The link-graph tools
The knowledge engine exposes a links tool whose kind selects a view of the graph. Four of these views are how you keep the graph healthy:
| View | What it surfaces |
|---|---|
dead | Links that point at documents that don't exist: broken references to fix or remove. |
orphans | Documents nothing links to: knowledge that's effectively unreachable. |
hubs | The most-linked-to documents: the natural centers of gravity in your KB. |
suggest | Likely-missing links between related documents: connections worth adding. |
Agents use these to repair and densify the graph as they work, instead of letting it rot.
Closed-loop grounding
Every factual claim should trace back to a source inside the knowledge base. External material is pulled in and cited locally rather than linked off to the open web, so the knowledge base stays self-contained and auditable. This is the backbone of the source-grounded workflows: see the LLM wiki workflow and the Entity vault (GBrain-compatible) workflow.
Attribution and collaboration
Every change made through OpenKnowledge is tracked, with attribution to whoever made it: a human author or a specific AI agent. The change history is persisted in the file system with no dependency beyond git.
That gives you:
- A changelog of every edit across the knowledge base.
- Point-in-time history. Revert to any earlier state.
- Per-author views. See exactly what one human or one agent changed.
Browse this history and restore earlier versions from the editor's timeline.
Because humans and agents edit the same files through the same tracked layer, collaboration is a first-class property of the system rather than something bolted on.