Begin with a future question

A personal knowledge system should help its future user answer a question. It is tempting to begin by choosing an application, a folder taxonomy, or an elaborate graph. Those choices are secondary. First identify the situations in which a past note would be valuable: repeating a technical procedure, remembering why a decision was made, or locating a useful source.

A note with a clear title and enough context to answer one future question is more useful than an impressive directory tree full of fragments. Start small and preserve the evidence that made the note worth keeping.

Separate capture from understanding

Capture is intentionally low-friction. It can include excerpts, URLs, ideas, or rough observations. Understanding takes a second pass: identify the central claim, explain it in your own words, and say when it applies. For technical work, distinguish documentation from your own observation.

A workable three-stage loop is:

  1. Capture: write down the item without interrupting the task.
  2. Clarify: add a meaningful title, source, and a short explanation.
  3. Connect: link it to an existing project, decision, or question.

Not every captured item deserves a permanent note. Deleting low-value material is part of curation, not a failure.

Store provenance alongside claims

A useful note records what came from a source and what you inferred. Include the document title, a stable URL or identifier, the date you accessed changing material, and any relevant version number. For an experiment, keep the commands and environment that produced the observation.

---
title: "Why this backup strategy was chosen"
kind: decision
status: current
source: "Internal design notes"
review: when-storage-changes
---

The example is a format illustration, not a real decision record. Metadata should remain understandable without a custom parser.

Resist taxonomy debt

Broad folders can help navigation: projects, references, decisions, and archive are often enough. Overly specific folders force you to decide where a note belongs before you know its future uses. Links and search can express relationships that a single directory path cannot.

Use consistent naming. Prefer dns-recursive-resolution.md over notes-final-3.md. Filenames should be stable, readable, and meaningful outside the application that created them.

Review where change matters

Some notes describe durable concepts; others describe software versions, active procedures, or policies that will expire. Mark the latter for review when the underlying system changes. A useful maintenance strategy reviews high-risk operational notes first instead of trying to revisit everything on a calendar.

Notebook principle: a system is successful when it helps you reconstruct a decision, not when it collects the most information.