# Core Concepts (https://openknowledge.ai/docs/reference/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](https://openknowledge.ai/docs/get-started/overview); if you want to start using it, see the [Quickstart](https://openknowledge.ai/docs/get-started/quickstart).
## Three layers
OpenKnowledge has three layers working together:
- a surface you edit
- an engine that keeps it consistent
- the files underneath
```html preview
↓ ↓ ↓
your-project/ · *.md
plain markdown, versioned by git
All three operate on the same files. Nothing locks you out.
```
- [The editor](https://openknowledge.ai/docs/features/editor): The application you see: a beautiful, themeable markdown editor that renders rich extensions (Mermaid, LaTeX, video and asset embeds, callouts, collapsible sections, interactive HTML) and lets you read and write your knowledge base directly.
- [The knowledge engine](https://openknowledge.ai/docs/reference/mcp): The framework underneath: an MCP server that lets any AI agent read and write your knowledge base while keeping front matter consistent, references intact, and the link graph healthy.
- [The content](https://openknowledge.ai/docs/reference/core-concepts#the-file-system-is-the-database): The files underneath: plain markdown in your own project directory, version-controlled by git. This is the durable layer the other two operate on, described in detail below.
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](https://modelcontextprotocol.io), 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](https://openknowledge.ai/docs/reference/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.
```html preview
Write the link once; OpenKnowledge records the backlink on the target for you.
```
> **Info**
>
> Backlinks are the payoff of ordinary linking. Every internal link you write earns a backlink on the target for free, so the graph grows as a side effect of normal writing.
## 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](https://openknowledge.ai/docs/reference/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`](https://openknowledge.ai/docs/reference/mcp) 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.
```html preview
```
### 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](https://openknowledge.ai/docs/workflows/karpathy-llm-wiki) and the [Entity vault (GBrain-compatible) workflow](https://openknowledge.ai/docs/workflows/entity-vault).
> **Info**
>
> OpenKnowledge is unopinionated about which workflow you adopt; these are supported patterns, not requirements. Grounding, backlinks, and the graph tools work the same regardless of how you choose to organize.
## 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.
```html preview
Every edit is attributed — a human or a specific agent — and revertible, with nothing 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](https://openknowledge.ai/docs/features/timeline-and-recovery).
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.