Graphkasten

Graphkasten is an AI-native evolution of the Zettelkasten, designed for graph-centric note taking. It is built primarily around Obsidian and its tooling.

There is a working example at github.com/jakub-zovi/graphkasten, an Obsidian vault with real notes that implements everything described below. Clone it and open it in Obsidian to see the folder layout, the links, the tags and the graph in one piece. And you can view my public Graphkasten here https://graphkasten.com/.

Most people treat Obsidian graph view as a nice little gimmick. In Graphkasten it is the primary way you move around the vault: you navigate the global graph rather than a folder tree, steering toward a cluster of notes (Fig. 1). Because every node takes its colour from its tag, the clusters are your topics of interest, giving you birds eye view of the vault. A local graph then gives you instant context around any single note. The premise is that the connections between notes matter as much as the notes themselves, and often more. Tthe graph approach also makes the system safe to point an AI at: agents can index aggressively, because the graph turns their work into something a human can review.

Fig. 1 The global graph of a Graphkasten vault. Every node is a note in topics/, and its colour comes from its tag, hence natural clusters are formed that I use to navigate the vault.

Latent Space Engineering

Four systems get cited whenever someone sets out to build a second brain:

• Zettelkasten by Niklas Luhmann, the ancestor of all of them: take notes of atomic ideas, index them, and cross-link them.
• PARA and CODE by Tiago Forte, which arrive as a pair. PARA defines a folder structure based on how actionable a note is, while CODE specifies how information gets processed.
• LLM Wiki by Andrej Karpathy, the newest of the four and the most direct about AI: let an LLM build the personal wiki.
• Open Knowledge Format by Google, which comes at the same material from the data-sharing side.

The first two are not designed for heavy AI use. The other two are broad, and aimed more at AI than at humans. The specifications of all four are too abstract and generic. None of them leverages Obsidian’s features, because none was designed for it. They are missing a process for keeping a vault maintainable, and they offer no guide for extracting insights from what has been collected. What they leave you with, in practice, is a second brain that behaves like a data dump. What we want instead is a second brain that both AIs and humans can use.

The deeper reason is that personal knowledge management operates in latent space, as opposed to the deterministic space of code.

Markdown is actually code now. The compiler is LLM. Garry Tan, YC

In the deterministic space there are compilers, tests and code review. In latent space there are currently no well-defined review processes and no design patterns, so a vault accumulates context rot and its structure degrades (Fig. 2). Building a second brain is latent space engineering, and doing it well needs the same kind of discipline that code already has.

Fig 2. Deterministic space has a toolchain that catches drift. Latent space, so far, does not, and closing that gap is what Graphkasten is for.

Graphkasten Components

Graphkasten defines three things:

• A design pattern, which specifies how to design and structure notes and the content of the vault.
• A review process, which explains how new notes get created and indexed in a maintainable fashion.
• Insights, which covers getting useful info back out of the second brain, using Obsidian tools like Graph View, Bases and tag folders.

Desing Patterns

The design pattern rests on four primitives:

• Folders define the structure, using the LIFT system described below.
• Links create the meaningful edges of the graph.
• Tags define areas of interest and highlight the graph.
• Frontmatter provides the metadata that Obsidian Bases query.

Folders

The vault uses the LIFT system, which splits it into four folders:

• Landing
  – Where all notes land before being sorted into the other three.
• Infra
  – Obsidian plugins, scripts and data files, such as bases, templates and attachments like PDFs, video and audio.
• Fleeting
  – Timeline-based notes such as daily notes, kanban notes and AI conversations.
  – These are filtered out of the global graph view
• Topics
  – All the areas of interest, and the only folder displayed in the global graph, because those notes are defined by their topography
  – Examples: finances, knowledge management, computer science, health.

That timeline-versus-topography split is the load-bearing distinction of the whole folder system, and it is the reason the graph stays readable as the vault grows (Fig. 4).

Fig 4. Timeline-based notes against topography-based notes. Source: A Brief History & Ethos of the Digital Garden

Links

Links are the most important object in Graphkasten, because they are what the graph is actually made of. The goal is to create links that are meaningful to your own mind. You should avoid over-linking, which pollutes the graph until it stops telling you anything. You can still connect nearly everything: use Obsidian URLs for the connections that are not important, since they let you click through without adding a graph edge. A good starting point is to mirror the natural hierarchy of the notes, the one already expressed in the folder tree, and then bend the links as your thinking about the material changes.

Get Jakub Zovak’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

There are three link types, and the choice between them is the whole discipline (Fig. 5):

• Wiki links, [[Note Title]], are resolved edges in the graph.
• Placeholder links, [[Not Yet Written]], are unresolved stubs that render red in the graph and read as a TODO.
• Obsidian URLs, obsidian://open?vault=…&file=…, are click-throughs with no graph edge at all.

Fig 5. Resolved links, placeholder stubs and edge-less Obsidian URLs, as they appear in the graph.

Tags

Tags define the topics in your vault. Unlike folders, they are deliberately shallow in Graphkasten: only one level of nesting is allowed. Each tag is associated with a colour, and that colour is what highlights its notes in the graph view, which turns a tagging decision into something you can see rather than something you have to remember (Fig. 6).

Fig 6. Colour groups, defined once per tag and denoting particular topic.

Frontmatter

Frontmatter is queryable metadata that Bases, agents and templates all read. Field names should be unified across the vault, and Obsidian templates are the practical way to keep them that way, one template per note type. The minimal shape is:

---
tags:
  - gen_ai/agents
created: 2026-09-27T10:00
modified:
sources:
  - "[Some source](https://example.com)"
topics:
  - Agent Design
authors:
  - Jakub
ai-assisted: true
---

Review Process

The review process is inspired by medallion architecture: every note flows through the same stages, getting more structured at each one (Fig. 7).

• Inbox: new and clipped notes drop into landing/
• AI indexing: an agent reads the note, writes its frontmatter, files it under topics/<cluster>/, and links it to the graph.
• Graph view: the note shows up as a new node coloured by its tag and connected within the global graph.
• Human review: you should check the graph and fix wrong edges. The goal is to keep the graph meaningful to your mind.

Fig 7. The review pipeline. Each stage narrows what a note can still be wrong about.

Insights Extraction

Global & Local Graph View

The global graph is both the map and the way you travel it. Colour groups defined at the tag level turn it into a picture of your topics of interest, so you locate material by steering toward the cluster it belongs to, and a note sitting in the wrong colour is visible immediately. That is what also makes it the audit surface after AI indexing, the place where a badly filed note is obvious. The local graph shows a single note’s neighbourhood at a chosen link depth (Fig. 8). For the depth, filter and colour-group syntax behind both, see the Obsidian Graph view documentation.

Fig 8. A local graph: one note and the neighbourhood that gives it context.

Bases

Obsidian Bases turn any folder or tag query into a live table, card or kanban view driven by frontmatter. You can slice notes by any field: a reading list by status, papers by citation count, tasks by priority. This complements the graph rather than duplicating it, since the graph shows structure and bases show attributes. Bases are defined in infra/bases/, such as Book View.base (Fig. 9).

Fig 9. A base over the vault’s book notes, the same notes as in the graph, queried by attribute instead of structure.

Tag View

Obsidian’s dedicated tag panel lets you browse the vault by tag hierarchy rather than by folder (Fig. 10). Because colour groups are defined once at the tag level, the same decision that organises this panel is what creates the natural clusters you see in the graph view.

Fig 10. The tag panel, browsing by hierarchy.

Conclusion

Graphkasten treats the graph viewas the primary navigation and review tool. LIFT keeps AI-generated noise out of the graph, and the review pipeline keeps the structure from rotting. Bases and the tag panel turn the same notes into query-driven views without duplicating any data. The result is a second brain that stays legible and auditable as it grows, and provides easy context retrieval for your AI.

References

1. Graphkasten example vault, an Obsidian vault implementing this specification
2. Zettelkasten, the method of Niklas Luhmann
3. PARA by Tiago Forte
4. CODE / Building a Second Brain overview by Tiago Forte
5. LLM Wiki by Andrej Karpathy
6. How the Open Knowledge Format can improve data sharing by Google
7. A Brief History & Ethos of the Digital Garden by Maggie Appleton
8. Graph view documentation by Obsidian
9. Bases documentation by Obsidian