The expedition’s five chapters cluster around one cross-cutting decision: what to do first when the scaffolding already exists but has never been used. All five recommend “habit before system,” but their individual adoption orders differ — and for a 1,200-note vault with unused templates and .base files, that order needs reshuffling.
Properties are the load-bearing prerequisite, not Bases. Two chapters independently arrive at the same gating step: a .base file is empty until the notes it points at carry consistent YAML frontmatter [1]. Bases ignores inline key::value Dataview metadata entirely [2]. For a vault with hundreds of reference notes and dormant .base files, the first move is therefore not “use the Base” but “stamp 3–4 properties (type, status, rating, date) onto one reference folder — books, films, recipes, or places — until its matching Base lights up” [3]. The Bases chapter calls this the five-step conversion workflow; the Properties chapter calls it the four-properties-and-one-Base proof step. Same move, different vocabulary.
Don’t backfill — tag and link forward. All five chapters converge on this. The linking chapter is explicit: re-organising folders to chase a perfect tree is Never [4]. The properties chapter: “tag forward from the day you settle the taxonomy; old notes get tagged only when you re-open them” [3]. The capture chapter: build the habit before the system [5]. For a 1,200-note vault, this is the single most important constraint — the temptation to retro-organise is exactly what burns the time that should go into new linking discipline.
A real order for this specific user. The chapters individually present linear paths; collapsed for an existing-vault, never-used-the-features developer it becomes:
- Pick one reference folder, stamp four properties on its template, wake up the matching
.basefile [3]. - Adopt the one-wikilink-before-close rule on new notes only [6].
- Switch on the five-line daily-note template and a single capture hotkey — no Periodic Notes yet [5].
- Once new-note volume exposes orphans, create three MOCs over the existing reference collections, Dump → Lump → Jump [7].
- Layer Quick Switcher++ and the keyboard hotkeys when the file explorer becomes the bottleneck.
Tensions left unresolved. The linking chapter pushes “tags are for status/type, not topic”; the properties chapter allows broad topic tags as one of three categories. Both are right at different scales: at 100 notes, restricting to status/type/topic with two tags max is wise; at 1,200 notes, topic tags are already in the wild and pruning them costs more than tolerating them. The expedition also doesn’t go deep on mobile sync trade-offs (Obsidian Sync vs Obsidian Git vs Remotely Save vs Self-hosted LiveSync) — a known gap that matters once Step 3’s capture hotkey extends to a phone.
The sharpest open question after all five chapters: is the bottleneck the unused scaffold, or the daily-note habit? If the templates and .base files already exist but no new notes flow in, no amount of property-stamping pays off. The Bases chapter has the proof-step; the capture chapter has the habit. Run them in parallel, not in series.