A Knowledge System That Compounds Instead of Accumulates

I keep a fairly serious note vault — it’s where I think through problems, and it’s the source material for a lot of what ends up here. The thing I had to learn the hard way is that capturing notes and using notes are completely different activities, and almost every system (including every one I built early on) optimizes only for the first. Capture feels productive and has no stakes. Use is where the value is, and it’s harder. A knowledge base that compounds is one designed around use from the start; one that just accumulates is a graveyard with good intentions.

Capturing is not using

Capturing is highlighting, clipping, jotting. It feels like progress because the information is now “safe.” But safe-in-a-pile and retrievable-when-you-need-it are different states, and the gap between them is where most notes go to die. Using a note means the right one surfaces at the moment you’re making a decision or writing a thing, and you synthesize it into something new.

The measure of a knowledge system isn’t how much you’ve saved. It’s how often something you saved changed what you did next.

That reframe is uncomfortable because it means a 5,000-note vault that never resurfaces anything is worth less than a 500-note one where each note has earned its keep. The metric that matters is the contribution rate — how often a note actually fed a decision, a piece of writing, or an action — not the note count. Optimize for that and the system compounds; optimize for volume and you’ve built a hoard.

Organize by what a note is for, not what it’s about

The most useful organizing idea I’ve adopted sorts notes by actionability rather than topic — the spirit of Tiago Forte’s PARA method. Roughly: active projects with an end date, ongoing areas of responsibility, reference material, and an archive for anything inactive. The win is that you place a note by asking “how alive is this?” instead of agonizing over which topic bucket it belongs in, and the structure doubles as a ladder from “working on it now” down to “cold storage.”

The deeper point is that topic-based folders fragment related thinking and force false choices (does this go under “networking” or “security”?), while actionability-based structure tracks how you actually work. You don’t retrieve notes by their Dewey decimal number; you retrieve them because you’re doing something.

Folders, tags, and links each have one job

When the three organizing tools blur together, the system gets noisy. They work best with a clean division of labor:

• Folders answer what kind of thing is this (and how actionable). A note lives in exactly one.
• Tags answer what’s it about / what state is it in — flat, multi-valued, good for filtering. Keep them few and meaningful; a tag that duplicates the folder is pure noise.
• Links answer what’s it related to. This is the real semantic structure, and it’s the one most people underuse.

The trouble starts when folders and tags encode the same fact. If a folder already says “infrastructure,” tagging every note inside it #infrastructure adds nothing but clutter. Give each tool one job and the whole thing stays legible.

Links and index notes beat deeper folders

As a vault grows, a deep folder tree gets worse, not better — every note forces a single-home decision, and related things scatter. The thing that scales is links, plus index notes (call them Maps of Content) that act as curated hubs into a topic. You find a note not by remembering which folder you filed it in, but by starting at a relevant index and following the links.

This matters because knowledge is a graph, not a tree. The same idea legitimately belongs to several topics; a link lets it be reachable from all of them without being copied, while a folder forces you to pick one and hide it from the rest. Build the navigation layer out of links and indexes and you stop losing notes to the question “where did I put that.”

Add an output stage, or it’s just storage

The piece most systems omit is a place for finished output — the articles, decisions, and write-ups you actually produced from your notes. Keeping that in the system, visible, does two things. It makes the link between raw notes and real work explicit, and over time it shows you which notes were generative versus which just sat there. That feedback loop is what lets you tune how you capture: you start collecting more of what’s proven useful and less of what never resurfaces.

A few small capture habits feed this loop cheaply. When I jot something, I try to also note what it connects to and where I might use it — the context of relevance is freshest at capture time and nearly free to record then, and impossible to reconstruct later. A note that ships with “this could apply to X” is far more likely to actually resurface when X comes up.

The throughline is that a knowledge base is a system with inputs, processing, and outputs — not a drawer. Design it around use, give your organizing tools distinct jobs, connect generously, and keep score by contribution rather than volume. It’s the same “documentation is part of the system, not an afterthought” instinct I wrote about in documentation is infrastructure, pointed at my own head instead of a codebase. If you’re rebuilding your own second brain and want to compare notes — literally — I’m easy to reach.