---
title: "Obsidian: Vault Structure"
slug: "obsidian-vault-structure"
category: "tooling"
tags: ["tooling", "obsidian", "knowledge-base", "zettelkasten", "moc", "notes", "organization"]
status: "stable"
last_updated: 2026-08-29
summary: "Design an Obsidian vault with MOCs over folders, atomic notes, daily notes as scratch, and a template on every note type."
related: ["[[tooling/obsidian]]", "[[tooling/obsidian-templates]]", "[[tooling/obsidian-plugins]]", "[[tooling/obsidian-publishing-to-quartz]]", "[[file-organization/folder-hierarchy]]", "[[file-organization/naming-conventions]]", "[[knowledge-vaults/vault-architecture]]", "[[knowledge-vaults/atomic-notes]]"]
---

## Overview

Vault structure determines how fast you find notes, how well links propagate, and whether the vault can publish without a transform step. The rules on this page produce a vault that is navigable by humans, queryable by Dataview, and publishable directly through [[tooling/obsidian-publishing-to-quartz]] without renaming or restructuring. They align with the shallow-folder principle in [[file-organization/folder-hierarchy]]. For a research vault with typed note schemas, decision journals, and an auditor, start from [[knowledge-vaults/vault-architecture]] instead; this page covers the plain publishing vault.

## Use MOCs over deep folder trees

A Map of Content (MOC) is a note that links its neighbors. Navigation flows through links, not directory traversal.

- Create one `index.md` per top-level domain folder. It lists all notes in that domain.
- Limit folders to two levels deep: `backend/` is fine; `backend/postgres/migrations/` is not.
- A note belongs to one folder for filing purposes, but can be linked from multiple MOCs. Folders cannot overlap; links can.
- When you cannot decide which folder a note belongs to, create it in the closest one and link it from the other. The link is the relationship, not the folder.

The payoff: a new note is one `[[wikilink]]` away from being navigable from anywhere in the vault.

## Separate daily notes from atomic notes strictly

Daily notes are scratch space. Atomic notes are the durable knowledge base. Mixing them degrades the signal-to-noise ratio of both.

```
vault/
├── daily/           # YYYY-MM-DD.md scratch files
│   ├── 2026-05-14.md
│   └── 2026-05-13.md
├── backend/
│   ├── index.md     # MOC
│   └── postgres.md  # Atomic note
└── coding/
    ├── index.md
    └── pine-script.md
```

Daily notes get a date-based name and live in `daily/`. Atomic notes get a kebab-case slug and live in their domain folder. See [[file-organization/naming-conventions]] for the slug convention.

Promote a daily-note idea to an atomic note when it gets cited a second time. The second citation is the signal that the idea is durable enough to own a slug.

## Keep atomic notes short and single-topic

One note, one idea. If a note has more than two H2 sections that feel like separate topics, split it.

Aim for 300 to 700 words per note. Notes shorter than that are usually a stub or a definition (both valid). Notes longer than that usually contain two ideas. The constraint keeps notes reusable: a 200-word note on "ATR calculation" can be linked from a volatility note, a position-sizing note, and a stop-loss note. A 1500-word note on "position sizing with ATR" is harder to cite precisely.

Wikilinks are the join layer. Keep the notes small and the links explicit.

## Apply frontmatter to every note from day one

Every published note needs YAML frontmatter. The full schema is in [[tooling/obsidian]]. At minimum, set `title`, `slug`, `tags`, and `status` on creation.

Using [[tooling/obsidian-templates]] with Templater, you can inject the frontmatter automatically when a new note is created. Set the template as the default for each folder type in the Templater settings. This eliminates the friction of manually typing the schema on every new note.

## Name notes with kebab-case slugs

`backend/postgres-replication.md` is better than `Backend/Postgres Replication.md` for four reasons:

1. Quartz and other static site generators use the filename as the URL slug. Spaces become `%20` unless normalized.
2. Wikilinks with spaces require `[[Postgres Replication]]`; slugs use `[[postgres-replication]]`, which is unambiguous.
3. Lowercase filenames are case-consistent across Linux and macOS filesystems.
4. The slug is the canonical identifier. The `title` field in frontmatter handles the human-readable display name.

See [[file-organization/naming-conventions]] for the full kebab-case rule and its rationale.

## Place templates and attachments outside the content tree

Keep non-content files out of the folders that publish.

```
vault/
├── _templates/      # Templater templates
├── _attachments/    # Images, PDFs, embedded files
└── content/         # Everything that publishes
```

Prefix with `_` so they sort to the top and stay visually separate. Add `_templates` and `_attachments` to Quartz's `ignorePatterns` so they never appear in the published site. See [[tooling/obsidian-publishing-to-quartz]] for the full ignore configuration.

## Related

- [[knowledge-vaults/vault-architecture]]
- [[knowledge-vaults/atomic-notes]]
- [[tooling/obsidian]]
- [[tooling/obsidian-templates]]
- [[tooling/obsidian-plugins]]
- [[tooling/obsidian-publishing-to-quartz]]
- [[file-organization/folder-hierarchy]]
- [[file-organization/naming-conventions]]