The Lifecycle System

I've tried a whole host of digital note-taking and todo apps over the years. Each time I'd lose interest and revert back to pen and notebook.

With digital, the barrier to capture was always high. So was the barrier to maintenance. In a notebook I could just write. I never maintained a notebook either - no index, no table of contents - it was just an endless stream of notes jotted down on pages as they came to me. That was fine. Digital was always alluring because I could at least search. But I'd lose myself trying to fit notes into rigid folder structures or apply tags consistently, and eventually I'd give up.

Obsidian was one of those apps. I tried it. I drifted away. I came back. I drifted away again.

The tagging was always the first thing to break down. I'd start with a clean tag taxonomy, then watch it sprawl. Once there were too many tags I'd get anxious about whether I was tagging things consistently, and the anxiety would kill the whole practice.

This pattern isn't unique to Obsidian for me. I like the idea of organization. In practice, my life is rarely organized. My desk is usually cluttered. Every so often I clear it off completely and feel great about it, and then within a week the clutter is back. The cycle repeats.

Why I Came Back

What pulled me back was Claude. Specifically, realizing that LLMs are genuinely good at working with markdown files. I wondered if anyone had paired Claude with Obsidian. Turns out a lot of people have.

I let that sit for a while. Then my friend Gavin posted Claude Code meets Obsidian, describing how he runs Claude Code directly in his vault and uses a CLAUDE.md file to encode his conventions. He framed the pairing as a genuine "second brain" - not a chatbot with memory, but an agent with persistent context that actively maintains the knowledge system alongside him.

That was the first ah-ha moment. This wasn't just a note-taking tool anymore. It was a markdown corpus that an AI could reason about, organize, and extend.

That spawned all the research that led to this post.

The second ah-ha moment came later: I can just embrace the chaos. I don't need to maintain a perfect organizational system. I can let Claude do the heavy lifting.

Gavin put it well: he's great at capturing information, terrible at maintaining it. For me it's both. I'm terrible at capturing and terrible at maintaining. Notes I should have written never get written. Notes I do write never get organized.

But with Claude connected to my other tools - and aware of my vault structure and note conventions - I can ask it to fetch information, write the capture note, and file it correctly. The whole pipeline, from "I should remember this" to "it's in the right place and linked to the right things," becomes something I can delegate. What I need isn't a system that prevents chaos. I need a system that makes chaos manageable.

That reframing is what led to the Lifecycle System.

The Core Argument

Folders should represent where a note is in its development, not what it's about.

The default instinct when organizing notes is to create folders by topic. Marketing notes go in a Marketing folder. Code notes go in a Code folder. Book notes go in a Books folder.

This breaks down quickly. A note on content marketing strategy for a web development project is a marketing note, a project note, and a web development note. Folders force you to pick one. Every time you create a note you make an organizational decision, and those decisions compound into a structure that's rarely right six months later.

The problem isn't that folders are bad. The problem is that topics are the wrong axis to organize on. And topics are exactly the axis that generates the kind of fiddly overhead that burned me out in my previous attempts.

Prior Art

Three systems informed my thinking.

PARA (Tiago Forte, Building a Second Brain) - Projects, Areas, Resources, Archives. Organizes by actionability rather than topic. The distinction between Projects and Areas is useful. The Resources bucket is a black hole.

FINVA (Tim Miller, Obsidian Rocks) - Fleeting, In Progress, Notes, Views, Archives. Organizes by lifecycle stage. Notes flow through the folders as they develop. Organization happens through MOCs and links, not folder hierarchy.

Inbox + Daily Notes - A common Obsidian pattern. One folder for capture, one for journaling.

FINVA was the key insight. Once I saw notes as things that move through stages rather than things that belong to topics, the organizational problem dissolved. PARA and the Inbox/Daily pattern filled in the edges.

The Lifecycle System

Five core folders for the workflow, two supporting folders for utility:

Vault/
├── Collect/     - Capture
├── Refine/      - Development
├── Library/     - Permanent notes
├── Catalog/     - Navigation (MOCs and Bases)
├── Archive/     - Inactive
├── Daily/       - Daily notes
└── Resources/   - Templates and attachments

The names are mine. The structure is mostly Tim's FINVA with PARA sneaking back in at the Catalog layer.

Collect

Everything starts here. No structure, no organization, just capture. Random thoughts, meeting notes, half-formed ideas, links to read later.

Processed weekly. Each note either graduates to Library (if it's quick to finish), moves to Refine (if it needs work), or gets deleted.

Refine

Notes that need more than five minutes of work. This exists to keep Collect clean. Without it, long-running notes clog up the capture folder and discourage new captures.

The goal for anything in Refine is to eventually move to Library.

Library

Permanent notes. Finished, self-contained, and useful on their own.

Library has no subfolders. All my notes - regardless of topic - sit in one flat folder. Web development notes next to recipes next to book notes.

This is counterintuitive until you start using it. I never browse Library as a folder. I search, I follow links, I navigate through MOCs. The folder structure is irrelevant because I don't interact with it.

Catalog

This is where organization happens, and it's the most important folder in the system.

The name comes from a library analogy. In a real library, books are shelved by call number - a fixed physical location. That's not how you find a book. You use the catalog, which is a navigation layer that sits on top of the collection.

My Catalog does the same thing. It contains MOCs (Maps of Content) and Bases (automated collections that gather notes by tag, folder, or metadata) that organize Library notes from different perspectives. The notes themselves live in Library. The Catalog just points at them.

This is the one folder where I allow subfolders, because its entire purpose is navigation:

Catalog/
├── Projects/   - Work with end goals
├── Areas/      - Ongoing responsibilities
└── Topics/     - Knowledge domains

This is where PARA comes back. Projects and Areas aren't folders of notes - they're folders of MOCs that organize notes from Library. A Project MOC might link to fifteen Library notes scattered across different topics, pulling them into a coherent view for that project.

When a project completes, I archive just the MOC. The Library notes stay where they are, available for the next project that needs them. Knowledge is reusable. Projects are not.

The Catalog is also where specialized workflows live. I have a Catalog/Writing/ folder for longform projects where MOCs act as compile sources - section notes live in Refine, the MOC embeds them in order, and a compile script assembles the final draft. Dashboards and Indexes are similar extensions that make sense once the core system is running.

Archive

Completed project MOCs. Inactive area MOCs. Old Library notes I don't need active access to but want to keep.

Daily and Resources

Utility folders that sit outside the lifecycle. Daily notes are chronological by nature and don't flow through the workflow. Resources holds templates (markdown scaffolding for new notes) and attachments (images and other media embedded in notes).

Resources is the other exception to the "no subfolders" rule. Templates and attachments are fundamentally different kinds of utility files and separating them keeps both findable.

A Note on Tags

Tag sprawl was one of the things that burned me out on Obsidian in the past. Once you have fifty tags, you spend more time wondering if you're tagging consistently than actually writing notes. So when I designed this system I wanted tags to do as little work as possible.

I'm not using Obsidian as a todo organizer, so I don't tag workflow state. The folder tells me where a note is in its lifecycle. I don't need #status/todo on top of that.

Where tags are useful is as durable metadata - attributes that need to survive folder transitions.

Consider a project MOC. While active it lives in Catalog/Projects/. When the project completes it moves to Archive. The folder location now tells you the state (active vs. archived) but it loses the type (it was a project). If I tagged it #catalog/project when I created it, that classification survives the move. Same for #catalog/area and #catalog/topic.

That unlocks a genuinely useful pattern: Bases that query across both Catalog and Archive. "Show me every project I've ever run." "Show me all notes related to the Finances area, active or archived." The folder structure handles workflow; the tags preserve classification across that workflow.

This principle - tags for durable classification, not workflow state - is what makes a small number of tags extend a long way. I use a handful of other tags along these lines, most notably #win for capturing achievements and #idea for parking thoughts I don't want to lose. Both survive folder transitions and both get queried by Bases to surface content I'd otherwise forget about. I'll cover those in a follow-up post.

The rule I follow is simple. Backlinks connect ideas. Folders track workflow. Tags are reserved for durable classification. If something I want to capture fits the first two categories, it never becomes a tag.

Why This Works

A few things about this system I've come to appreciate.

Workflow and organization are separated

Folders answer "where is this note in its development?" MOCs answer "how does this note relate to everything else?" These are different questions, and conflating them is what makes topic-based folders painful. Separating them turns two hard problems into two easy ones.

Capture is frictionless

Everything goes to Collect. No decision required at the point of capture. This is the single biggest reason the system has stuck for me - the capture step doesn't require me to know where anything belongs, which is exactly the decision I'm bad at making in the moment.

Knowledge is reusable

Notes in Library aren't tied to a specific project or context. When I start a new project, I create a MOC that links to the relevant existing notes. I'm not copying knowledge between projects, and I'm not losing knowledge when a project ends.

The system scales

Adding a new project is a single file in Catalog/Projects/. Adding a new topic is a single file in Catalog/Topics/. Nothing restructures. Compare that to a topic-based folder tree, where every new project risks reshuffling folders or creating new ones.

It's flexible at the edges

The five-folder core stays stable. If I need dashboards, I add Catalog/Dashboards/. If I need a professional contacts directory, I add Resources/Rolodex/. The shape of the system can evolve without disrupting the core.

What I'm Still Figuring Out

This is version one. A few things I expect to evolve:

• How aggressive to be with archiving. I err on the side of keeping Library notes active. Too early an archive makes notes hard to find when they become relevant again.
• Whether Topics should be MOCs or Bases. MOCs give me control. Bases give me automation. I'll probably end up with both.
• Template conventions for Project, Area, and Topic MOCs. I have working versions, but I'm still iterating on what metadata and sections earn their place. Expect them to evolve.

Try It Yourself

I've published a starter vault on GitHub: alexmarnell/obsidian-lifecycle.

It includes the full folder structure, a CLAUDE.md with vault conventions, and two Claude Code skills I use daily: /sort processes the Collect folder and moves notes to their right homes, and /format enforces the vault's formatting conventions. Clone it, open it in Obsidian, and start capturing.

Credit

This system is 80% Tim Miller's FINVA with PARA sprinkled into the Catalog layer. If you're thinking about note organization in Obsidian, read Tim's original post on folders, his post on Maps of Content, and his introduction to Bases. He articulates the underlying philosophy better than I can.

Tiago Forte's Building a Second Brain is worth reading for the Projects/Areas distinction even if you don't end up using PARA directly.

The rest is just renaming and combining.