Growth With Friction: Organization, Maintenance, and Honest Extensions

For claude-obsidian, growth is not simply the addition of more notes or more automation. The specific question is how a vault can become easier to navigate and more capable without turning its folders, models, or diagnostics into unearned evidence. This chapter connects organization, linting, privacy controls, capability reporting, and optional extensions to the ownership and provenance rules already established, so readers can choose what to add and recognize when an automation path should stop.

Structure helps readers navigate; it does not make claims true

A growing vault needs structure because a source-cited page is useful only if a reader can find it and understand its relationship to other pages. claude-obsidian addresses that need with a declared page vocabulary, internal links, indexes, maps of content, and several filing methodologies. But it keeps organization separate from evidence. A page’s folder, title, or link density can improve navigation; none of those properties raises the page’s authority, freshness, or confidence.

The distinction begins with page types. The project’s vocabulary includes sources, entities, concepts, questions, comparisons, sessions, overviews, metadata pages, and folds. Some are routable: a new source, concept, entity, question, or session has a natural place in a filing methodology. Other types are deliberately structural. An overview, metadata page, or fold is created by a dedicated operation rather than routed like an ordinary note. This prevents the router from inventing a destination merely because a type is valid in frontmatter.

That small separation solves a larger maintenance problem. If the list of valid types and the list of types a router can place drift apart, an agent can produce a note that satisfies one part of the product while violating another. claude-obsidian declares the vocabulary once and derives the routable subset from it. It also distinguishes an unknown type from a valid type that is not routable. The result is not just tidier configuration. It gives a failed operation a more useful explanation: correct the value if it is a typo, or use the dedicated operation if the page is structural.

Filing methodologies then provide different answers to a navigation question: where should a new page go so that the user can find and maintain it later? Generic mode uses familiar typed folders. LYT emphasizes atomic notes connected through Maps of Content. PARA routes by actionability into projects, areas, resources, and archives. Zettelkasten uses stable identifiers and dense links. None is declared universally best, because the right choice depends on how a user retrieves and maintains knowledge.

The boundary around a mode is as important as the mode itself. Changing from Generic to PARA, or from one method to another, affects future routing. It does not silently move existing notes, rewrite links, create a new folder tree, or change the evidence semantics of old pages. A mode configuration is applied as a reviewed change, while a bulk reorganization would require its own move map, collision handling, link rewrite plan, expected hashes, and rollback strategy. The project refuses to turn a preference about filing into an unannounced migration.

Internal links and indexes play a similar supporting role. A wikilink can point a reader from a source summary to a concept, question, or related entity. An index or Map of Content can provide a curated entrance to a domain. A Canvas can place those relationships in space.