Drift‑Free Obsidian Vault Architecture (Oct 16, 2026)

Why a Knowledge Graph Designed in Advance Makes an Obsidian Vault Easier to Grow

1. Designing an Obsidian Vault

Most Obsidian vaults grow by creating new folders whenever a note no longer fits, so the resulting hierarchy reflects the order in which problems appeared rather than how the notes are actually used. While this approach is fast, renaming or moving files later, especially in a vault whose structure is still evolving, can be error-prone. Designing a knowledge graph and establishing the folder layout before you begin using Obsidian is therefore the crucial first step in my personal experience.

A reliable foundation can be obtained by using the following cross-platform PowerShell script Create-ObsidianVault.ps1. It scaffolds a top-level hierarchy of seven purpose-driven directories:

Numeric prefixes enforce a stable ordering in the file explorer, ensuring that the logical workflow remains consistent as the vault expands.

2. Blog with Parallel Editors: Obsidian-Vim

In a previous blog post, I described how Typst and a custom Vim9script power the engine of a static blog website. Here, I want to discuss why using two Parallel Editors as a true 1:1 Markdown link between Obsidian and Vim can be beneficial. Both applications read and write the same plain Markdown files, the same note can therefore be opened in Obsidian showing the rich preview/graph view, or in Vim, which provides fast, modal editing. Any change made in one editor instantly appears in the other.

Within Obsidian, drafts live in a richly linked graph, letting fragmented insights connect and mature. Opening the same Markdown file in Vim provides fast modal editing and the possibility to then promotes the draft version into a .typ file, ready for the final build.

The publishing stage is fully automated via GitHub Actions. A push of the promoted file to the repository’s main branch triggers a workflow that spins up a runner, invokes the Typst compiler, generates static HTML, and deploys it to GitHub Pages. By offloading compilation to the cloud, the local workstation remains a pure creative space.

3. AI Work Log

The second recurring element is the weekly tally of the AI Work Log, which is generated by a separate application from the cards saved after each chat. The tally is pasted into one note per ISO week. The core Daily notes plugin can create these notes when its date format is set to GGGG-[W]WW, where GGGG is the ISO week-year and WW the zero-padded ISO week number, which yields file names such as 2026-W42.md. The first request in a week creates the note from a template, and later requests open the same file. Below, you find an example of such tally.

4. Zettelkasten

The Zettelkasten folder is not free-form. It follows the numbering of the Index Card notebook, where an octagonal map carries eight nodes, each ticked from 1 to 20. The vault mirrors this scheme with eight folders, N1 to N8, and one note per card side, named exactly as the printed reference.

The graph view is used to reproduce the map. One colour group per node is defined with a path query, for example path:30_Zettelkasten/N3/, so that the eight categories appear as eight colours. This is a built-in feature and requires no plugin.

5. Skills and Prompts

The folder 50_Skills_Prompts contains a single note for each skill or prompt. Each note is created from the Skill‑Prompt template (saved in the Templates folder by the setup script). The template defines four fields:

  1. Name – the title of the skill or prompt
  2. Description – a brief overview of its purpose and usage
  3. Model – the LLM that should process the prompt (e.g., gpt‑4o, claude‑3.5)
  4. Temperature – the sampling temperature to control output randomness

To generate a new skill note, invoke Insert template from Obsidian’s core Templates plugin (enabled by default). The template inserts the four properties; below them you write the actual prompt text. This keeps every skill entry consistently structured and instantly searchable across the vault.

6. Conclusion

The central achievement of this architecture is pre-determining every name in the vault as far as the design stage allows. The nine top-level folders, the eight Zettelkasten node directories, the card labels such as N3-14F, and the weekly files like 2026-W42.md all stem from fixed conventions: the paper notebook’s numbering system and the ISO-week calendar. The only cost is a brief setup phase: run a one-time script, add a tiny custom plugin, and enable a few Obsidian settings that cannot be preset. After that bootstrap, the vault’s structure remains wholly prescribed, eliminating the need for any later ad-hoc naming or folder creation.