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 obsidian-publishing-to-quartz without renaming or restructuring. They align with the shallow-folder principle in folder-hierarchy.

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 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 obsidian. At minimum, set title, slug, tags, and status on creation.

Using 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 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 obsidian-publishing-to-quartz for the full ignore configuration.