How I keep notes and make decisions (current setup)

A description of the setup as of October 2026, written so I can see whether it still holds in a year. Two systems, deliberately separate: a knowledge base for reference material and a decision ledger for choices.

Knowledge base

Plain markdown in a private git repository, laid out in PARA: projects/ (finite efforts), areas/ (ongoing responsibilities), resources/ (reference), archives/ (inactive), plus an inbox/ for the unsorted. I moved it out of Obsidian in October 2026 after realising the GitHub app covered every editing need. The notes are kept portable on purpose — kebab-case filenames, standard relative links rather than wikilinks, heading anchors only, YAML frontmatter — so any editor works and nothing depends on one tool.

Public notes are the exception, and they live here rather than in the private tree: the notes, library, essays and talks on this site are the published subset, with a draft flag as the only gate. Publishing a note means moving it here and giving it this site’s frontmatter.

Decision ledger

Choices get a one-page decision brief — an architecture decision record for a life or work choice: context, the choice and its default alternative, a scorecard, a verdict, and consequences. Briefs live in per-context folders (personal, practice, software) and a decision in one context constrains the others. Statuses follow the ADR convention: a superseded decision is marked, never deleted.

The scorecard is five lenses, each +1 / 0 / −1:

1. Finish — does it advance something already in flight, or compete with it? (Jevons: cheap starting, fewer finishes.)
2. Judgment — is the pull from knowing the problem from inside, or from ease and novelty? (Baumol.)
3. DRIP — does it return value on the scarce axis and still energise in three months? (Martell.)
4. Reach — daily, weekly, or rarer? (Vaynerchuk.)
5. Carry-forward — what survives if it fails?

A sum of +2 or less cannot produce proceed — the 90% rule. Three gate questions follow (who is paying for this pain now; can it be observed five times first; what is learned if it fails), then precedent from the ledger, a five-voice council, and a forecast in my own words so the revisit is a calibration check. Decisions that bind for a long time, are hard to reverse, or put other people’s stakes on the line open a second page: a pre-mortem, 10/10/10, a stakeholder line.

One standing decision sits over all of it, from Burkeman: at most three active projects. Everything else — including good ideas, especially good ideas — waits.

Why two systems

The ledger holds what I decided and why; the knowledge base holds what I know and refer to. Keeping them apart means a reference note never quietly becomes policy, and a decision is always findable as a decision. The notes link to the ledger; they never copy it.