A personal knowledge base as plain-text folders: inbox, notes, sources, projects, archive

What it is

A personal knowledge base is the set of notes a person or an agent writes for their own later use: what was learned, decided, tried and read. Kept as plain text in a versioned folder, it outlives any application. The layout proposed here separates content by lifetime rather than by topic:

• inbox/ — anything captured quickly, unprocessed; expected to be empty after each weekly review.
• notes/ — one durable idea per file, written in the author's words, with links to other notes and to sources.
• sources/ — one file per book, paper, page or conversation, holding the reference, a short summary and the list of notes it produced.
• projects/ — working notes tied to something with an end date: plans, logs, decisions, open questions.
• archive/ — finished projects and superseded notes, moved rather than deleted, never linked to from notes/.

Every file starts with a small header (identifier, title, created date, tags, status) and carries its identifier in the file name so that links survive renaming. One index.md at the top lists entry points by topic and is edited by hand; a full-text search covers the rest.

Why it matters

Notes that live inside an application are lost when the application changes; notes sorted by topic get reorganised every time the topics shift, breaking links. Sorting by lifetime keeps the decision at filing time trivial (is this a source, an idea, a project?) and makes the weekly maintenance concrete: empty the inbox, move finished projects, update the index.

How to apply

• Keep the tree flat: no subfolders under notes/ and sources/; use tags and links instead.
• Write the note before filing the source, not the other way round; a source without a note is a bookmark.
• Use CommonMark with one heading per note and relative links, so that any viewer or an agent's file tools can read it.
• Version the folder (git or a synchronised copy with history) and commit after each review.
• For an agent, treat notes/ as the durable memory and projects/ as the scratchpad; load the index, not the whole tree, at session start.

Pitfalls

A growing inbox/ that is never processed. Notes that copy sources instead of stating an idea. An index that lists everything and therefore nothing. Deleting instead of archiving, which breaks links from older notes and from project logs. Nesting folders by topic "just for this area", which reintroduces the problem the layout avoids.

Archiving without breaking links

Links between notes are by identifier, never by path, and a link is resolved by searching every folder, archive/ included. Moving a note to archive/ then breaks nothing, and the rule 'never link into the archive' is unnecessary: the archive is a filter for the index and for search defaults, not a boundary for links. A superseded note keeps its identifier and gains a header line superseded_by: <identifier>, so a reader who follows an old link is sent on to the replacement; a finished project keeps its log unchanged. The exception is inbox/: a capture that was never linked and never processed can be deleted, since the only reason to keep files is to protect links into them.