I keep a lot of different kinds of information. A printer I researched and eventually bought. A blood pressure reading. My weekly dose of vitamin D, and when the next one’s due. Notes on how I filed a tax return, so the next filing is easier. A quote I liked. Poems. A prescription my doctor wrote out. Diary entries. License keys for software I’ve paid for. Ideas I want to hold onto but haven’t done anything with yet.
For a while I tried to organize all of this the obvious way: by subject based folders and tags. Health goes here, finance goes there, ideas go somewhere else. This organization broke almost immediately, for a reason that’s easy to miss until you hit it directly: a blood pressure reading and a note on how I do my taxes are both “personal admin,” but I will never look for them the same way. One is a number I want plotted over months. The other is a set of steps I’ll reread once a year, right before I need them. Filing them under the same topic tells me nothing about how to store or retrieve either one.
The fix turned out to be simple to state and slightly annoying to actually commit to: stop organizing by what something is about, and organize by how you’ll retrieve it when you need it.
A small set of types, shaped by how you’ll retrieve them
Once you ask “how will I retrieve this?” instead of “what’s this about?”, almost everything you’d ever capture sorts into a small number of shapes. For the content I keep, five has been enough:
- Reminder — has a due date or recurrence. You need to know when it’s due and whether it’s done.
- Record — a dated, factual entry, searched by date or by keyword, rarely edited after the fact. Blood pressure readings, a purchase, a prescription, a diary entry. Searched by date or by entity/keyword. The frequency determines the storage pattern. High-frequency observations (a measurement you take daily) belongs to a database or a single text note with one line per entry, so the history reads as a table. Low-frequency events get one note each. Narrative entries get dated prose notes. All three are the same type; only the volume differs.
- Project — an open thread with a real lifecycle: it starts, has active work, and closes with a decision or a result. Which printer to buy. A tax filing cycle. A goal with an end state. You look at it while it’s open and rarely again once it’s closed — but you don’t delete it.
- Reference — evergreen, stable-truth content, updated in place, looked up by name rather than browsed.
- Idea — atemporal, associative, no due date and no lookup key. You don’t search for these so much as stumble back into them through links.
Project and Reference are the two with a real lifecycle, so they’re the two that carry a status field: active, superseded (replaced by something newer, optionally linked to what replaced it), or archived. This is what keeps an old install guide from cluttering a search years after it stopped being true — it doesn’t get deleted, it just stops being the default answer. Reminder, Record, and Idea/Quote don’t need this — a Record’s age is informative on its own, and a Reminder is simply done or not.
The Reference type has subtypes
The Reference type turned out to have further internal structure once I looked closely at what actually lands there. Three subtypes cover everything I’ve thrown at it:
- Entity — a proper noun: a person, a place, a piece of software.
- Concept — an idea or topic explanation you’d re-explain to yourself later: a technique, a principle, a tradeoff you worked through once and don’t want to re-derive.
- Procedure — ordered steps you’ll execute again: a filing process, a server setup, a recipe.
This mirrors, not coincidentally, the entity/concept split Andrej Karpathy described in his own “LLM wiki” gist — evergreen personal wikis seem to converge on roughly this split independently, which is a reasonable signal it’s tracking something real rather than something I invented.
Tags are the other axis
Types answer “how is this stored and retrieved.” A second, independent axis — domain tags — answers “what is this about.” By default, these are flat rather than hierarchical. Hierarchies force a single-parent decision at the moment you file something, and that decision is often genuinely ambiguous. A curry recipe tagged cooking, curry, indian doesn’t require anyone to decide whether it lives under Food or Culture. It shows up under every lens that’s actually useful, and a tag can be renamed or merged later without moving a single file.
But that’s an argument against hierarchy doing the classifying, not against hierarchy existing at all. I have a cluster of notes about post-install setup steps for different machines — Linux servers, a Mac, a Windows box — and organizing those as computers/post-install/macos, computers/post-install/linux isn’t forcing a premature parent choice the way Food-vs-Culture was. The cluster is already decided; the nesting is just helping me browse inside it. That’s a legitimate, opt-in refinement within one tag that’s grown large enough to need internal structure — not a hierarchy tree imposed on the whole system up front. The failure mode flat tags actually protect against is being forced to pick the one true home for something that doesn’t have one; once a cluster has one, organizing its inside is a different, much smaller problem.
The other real risk with flat tags is drift — vps, vps-hardening, and self-hosting all meaning roughly the same thing. The fix is a light discipline, not more structure: classify new information against an existing canonical list of tags before coining any new ones, and do a ten-minute prune every month or so to catch near-duplicates (this can be done by an LLM and the task can be automated).
Type composition
Some real things don’t fit in any one type — they’re made of several, linked together. Tracking a relationship (family, a colleague you want to stay in touch with) is a good example: the person’s own facts live on an Entity page; “check in every two months” is a Reminder; each actual conversation is a dated Record, linked back to the Entity. None of these needed to become a sixth “Relationship” type — the existing three, composed, cover it completely.
The same pattern handles a lease with a renewal date (Reference for the terms, Reminder for the deadline) or a piece of software with an evolving license (Reference for what it does, Record for when you renewed and what you paid).
Pre-classification staging
Not everything starts life as one of these types. A half-formed thought, a link you want to read later, a voice memo you haven’t processed yet — these sit in a staging area outside the schema entirely: an inbox, an unread tag, a capture buffer. This is close to what Zettelkasten calls a fleeting note — not meant to be permanent, not yet classified, disposable once it’s been turned into something else or discarded. The schema in this post only describes what happens after that triage step, deliberately. Trying to make the five types also describe the pre-classification mess would blur a genuinely different problem — capture needs to be fast and unopinionated; classification benefits from being deliberate and structured. Keeping them separate is what makes both work.
The list is small, rather than final
I’ve used this schema extensively, but not enough time to claim that the five defined types are all there need to be. What I do think is true: the list of types should stay as small as it can reasonably be for the content you actually keep, and every candidate addition should have to earn its place by being a genuinely different retrieval shape.
Two examples of the test in action, both things that felt at first like they might need their own new type:
A journal or diary feels different — it’s personal, chronological, carries real weight for a lot of people who keep one. It’s tempting to give it a dedicated type. But run the actual test: is the retrieval shape different from anything else? No — it’s dated, searched by date or keyword, rarely edited after the fact. That’s exactly the Record type. The content feels different; the retrieval shape doesn’t, and retrieval shape is what the taxonomy/schema tracks.
Zettelkasten’s own fleeting/literature/permanent split looks, at first, like it might demand three types instead of folding into this schema at all. It doesn’t, once mapped through: fleeting notes are the pre-classification staging described above, outside the schema entirely. Literature notes — dated captures of what a source said — are Record. Permanent notes — your own synthesized thinking, revisited and linked — are Idea, or Concept if they’ve evolved into something you’d formally re-explain. A well-known trichotomy from an entirely different tradition maps cleanly onto three of our five schema types, which is a reasonable sign the underlying shapes are tracking something real rather than something specific to my own use case.
The discipline that keeps the list from sprawling isn’t “never add a sixth type” — it’s asking, every time a candidate shows up, whether it’s a genuinely new retrieval shape or just a new topic wearing a shape the list already has.
Where this sits relative to PARA and Zettelkasten
None of the underlying instinct here is new. PARA (Tiago Forte’s “Building a Second Brain”) already rejected topic folders in favor of organizing by actionability — Projects, Areas, Resources, Archive — for essentially the same reason: topic hierarchies force premature, brittle decisions. Zettelkasten already supplies the atomic-note, freely-linked model that Idea/Reference borrows directly, and the fleeting-note idea above is straight from the same tradition. GTD already treats action items as a fundamentally different retrieval pattern from reference material.
What’s a little sharper here is the lens itself. PARA organizes around actionability. This schema organizes around retrieval mechanism. Specifically: will I search for this by (due) date, by name, or find it by association? That’s a narrower, more mechanical question, and it produces a finer cut: PARA’s “Resources” bucket, for instance, contains at least three different retrieval shapes under one roof (a person you know, a how-to procedure, a decision-support document) — exactly the kind of blur that starts creating friction once a knowledge base gets large enough. Think of this schema as PARA and Zettelkasten pushed a step further towards retrievability, rather than a replacement for either.
Access control is orthogonal
Somewhere in almost every conversation about this system, the question of access control comes up: should this note be visible to my spouse, my team, anyone at all? That’s a real concern but it is orthogonal to everything above. Retrieval shape doesn’t change based on who’s allowed to see something; a license key and a grocery list can both be Reference pages, but only one of them should probably be encrypted or excluded from a shared vault. For a single person’s personal system, this mostly doesn’t bite. It would need its own answer entirely — a permissions layer sitting across the whole taxonomy — the moment more than one person is reading from the same vault.
How I actually use it
In practice, I don’t file any of this by hand. I run a small personal automation layer — a Hermes agent — that receives whatever I wish to capture (a typed note, a dictated thought, a forwarded photo) and classifies it into one of the five schema types, tags it, and routes it to wherever that type actually lives: a task manager for Reminders, a small structured database for certain Records, a personal wiki for Project/Reference/Idea and Records. The schema in this post is deliberately independent of that machinery. It is the classification model, not the implementation. So it stays useful whether you’re filing things by hand into folders, into Obsidian, or letting an agent do the filing for you.
Try it
Right now the schema contains five types, a flat-by-default set of tags, an optional status field for anything with a lifecycle, and one governing question to ask before adding anything new: is this a genuinely different way I’ll need to get something back, or just a new thing I’m keeping? If it’s the latter — and it usually is — it’s a tag. If it’s the former, add it as a new type.
(Small note: I developed and stress-tested this schema in conversation with Claude, Anthropic’s AI model — genuinely useful for pressure-testing edge cases that I have yet to hit.)