Summary
[!note] 📚 Obsidian Vault Organization Series
- What I Found When I Audited 198 Projects ← you are here
- 240 Orphaned Tasks: When Capture Outpaces Processing — May 4
- 5 Lessons from Reorganizing 8,333 Tasks — April 13
Every productivity system reaches an inflection point where the overhead of maintaining it starts to exceed the benefit of using it. You know you’ve crossed that line when you’re spending more time organizing tasks than completing them — when “file this under the right project” has become its own project.
My Obsidian vault reached that point at the end of 2025. Three years of accumulation: personal projects, family responsibilities, solo business ventures, and work tasks, all managed through a single vault with custom Python automation scripts. The vault was working — tasks were being processed, projects were moving — but the underlying structure had drifted into a state that was difficult to audit and impossible to understand at a glance.
So I ran an audit. What I found was more systematic than I expected, and more revealing about how knowledge management systems fail over time.
The Scope: What the Audit Covered
The audit focused on project files — the .PRJ. files that are the primary unit of tracking in this vault system. Every project gets one file. The file contains the task list, sub-project breakdown, metadata, and any external notes generated during the work.
Over three years, that collection had grown to 198 project files:
- 68 solo projects — personal business ventures, side projects, and solo learning
- 49 family projects — home management, health, children’s activities, and family planning
- 81 work projects — professional responsibilities at an enterprise employer
That breakdown was the first surprise. I knew the vault was large, but the distribution told me something about where my attention actually went: work projects outnumbered solo projects by nearly 20%, despite the fact that the solo projects were the ones I wanted to prioritize.
If your project count by category surprises you, that mismatch is your real prioritization data — not your intentions.
The Numbers: What 198 Projects Looks Like
The audit script generated the core statistics:
| Metric | Value |
|---|---|
| Total project files | 198 |
| Total tasks | 8,333 |
| Completed tasks | 3,922 |
| Undone tasks | 4,411 |
| Completion rate | 47.1% |
| Tasks with dependency IDs | 984 |
| Duplicate file numbers fixed | 28 |
The 47.1% completion rate is the number that deserves the most attention. On the surface, it sounds like the vault is half-done — but that framing is wrong. A task management system that’s 47% complete isn’t failing; it’s a living system where new work is constantly being added. The meaningful question isn’t what percentage is done, but whether the undone tasks represent work that’s actively moving or work that’s quietly accumulating without ever being touched.
The 984 tasks with dependency IDs meant that the dependency graph between tasks was already formalized. Tasks with 🆔 markers had explicit identifiers; tasks with ⛔ markers were blocked on other tasks. This was actually encouraging — it meant the system had structure. But it also meant that any duplicate IDs in that graph would create false dependency loops and block tasks incorrectly.
28 duplicate file numbers was the structural finding. Over time, files had been created with numbering that collided with existing files — three different projects assigned to 34.10, two different PRJ files both numbered 202.004. Duplicates don’t just create organizational confusion; in this vault system, they cause the automation scripts to process the wrong file and write results to unexpected locations.
The Three Phases of the Audit
The audit ran in three sequential phases, each building on the findings of the previous.
Phase 1: Scan and Inventory
The first phase mapped the existing state without changing anything. Three questions drove it:
-
How many undone tasks exist in the daily notes, and how many are linked to projects? The daily notes are where tasks get captured before being sorted into project files. If captured tasks aren’t being moved to their project files, they accumulate as undone work that’s invisible to project tracking.
-
Which project files have duplicate numbering? The PARA-based numbering system (
202.XXXfor solo projects,302.XXXfor work projects) requires unique numbers. Duplicates anywhere in the system break the addressing assumption. -
Which projects have sub-projects that are ambiguous, over-large, or structureless? A sub-project with 80 tasks and no phase breakdown isn’t a sub-project — it’s a backlog with a header.
The scan of daily notes found 243 undone tasks across three years of daily note files. Of those, only 3 were linked to project files — 1.2%. The other 240 were orphaned: captured but never sorted, referenced by nothing, invisible to every project query.
I’ll cover what those 240 orphaned tasks reveal in the next post.
Tasks captured in daily notes but never linked to a project are invisible to every query. They accumulate silently — and 98.8% of mine had.
Phase 2: Fix Structural Problems
With the inventory complete, Phase 2 addressed the structural issues:
Duplicate file numbers were resolved in four batches. The numbering fixes cascaded — fixing a duplicate in the 34.XX range meant updating every wikilink that referenced the renamed file. Across 28 fixes, that was hundreds of link updates.
Over-large sub-projects were broken down. A sub-project with 96 tasks — discovered in a resources project — wasn’t restructured because the audit confirmed it was already organized; the task count was deliberate. A blog automation project with 102 tasks was reorganized with MVP phases and dependency ordering. The difference between “large but structured” and “large and undifferentiated” matters: the structured one is manageable, the undifferentiated one creates decision paralysis every time you open it.
Misplaced tasks — tasks that had ended up in the wrong project file after intake processing — were identified and moved. The intake sorter automation follows the first wikilink in a task description; any task that linked to the wrong project ended up in the wrong file.
Phase 3: Process by Category
The final phase processed projects by category — solo, family, and work — applying consistent sub-project structures where they were missing and adding dependency ordering where tasks had implicit sequence but no explicit markers.
The work projects were skipped at the user’s request. Enterprise work has organizational structures that don’t always map cleanly to a personal vault’s conventions, and some work information belongs in work systems rather than in a personal knowledge management vault.
The solo and family projects were fully processed. For family projects specifically, the audit revealed something interesting: the largest family project file had 111 tasks across a single unlabeled section. Reorganizing it into eight focused sub-projects (Medical, Home Maintenance, Financial Benefits, Shopping Lists, Daily Organization, Gmail Management, Transportation, Special Occasions) didn’t add any new tasks — it just made the existing work visible in a form that could be acted on.
Reorganizing 111 tasks into 8 sub-projects didn't add any new work — it made the existing work visible.— Full Bright, Bright Softwares (bright-softwares.com)
What a 47.1% Completion Rate Actually Means
A knowledge management system with a 47.1% completion rate isn’t broken. It’s doing exactly what this kind of system is supposed to do: capturing everything, not just the things that are easy.
A system that only captures easy, completable tasks would have a 90%+ completion rate — and would be missing all the long-horizon work, the aspirational projects, the research threads that take months to resolve. The 4,411 undone tasks in this vault include projects that are actively in progress, projects that are on hold waiting for external events, projects that were captured as ideas and are still waiting for prioritization, and yes — some tasks that were added and probably never should have been.
The audit couldn’t tell me which was which. That required a different kind of analysis: looking not at the completion rate, but at the structure of the undone work.
That’s where the 240 orphaned tasks come in.
→ Next: 240 Orphaned Tasks and What They Reveal About Knowledge Management Systems
