PARA and CODE, filing notes by actionability

Tiago Forte taught a course called Building a Second Brain for years before turning it into a book of the same name in 2022, followed by a shorter book on the filing method alone, The PARA Method, in 2023. The essay that started it, on the Forte Labs blog, predates both and is still the most compact statement of the idea.

The two acronyms do different jobs and are often confused. PARA is the structure: four folders and a rule for choosing between them. CODE is the workflow: four steps that take a piece of information from the moment you notice it to the moment it is part of something you made. PARA is the O in CODE. You can adopt PARA alone, and many do, but CODE is what stops it becoming a tidy archive nobody reads.

The insight worth taking from PARA is one sentence long: organise by how actionable something is, not by what it is about. Everything else follows from that, and if you only change one thing about your notes, change this.

A subject tree is the instinctive default. You make a folder called Marketing, one called Finance, one called Health, and you file each new thing into the topic it belongs to. It feels like the right thing to do because it is what libraries do, and it fails for personal notes for three reasons.

• Most items are about more than one thing. A supplier contract is finance, legal, and the office move. A folder forces you to pick one, and the one you pick is the one you will not think of when you go looking.
• The right category depends on why you saved it, and that changes. An article on pricing psychology is a general interest until the week you are rewriting the pricing page, at which point it belongs next to that work. A subject tree cannot express that difference, because the subject did not change.
• A subject tree grows a long tail. Given eighteen months it becomes forty folders, most holding one item, plus a decision each time about whether a new thing deserves a folder of its own.

The deeper problem is that a subject tree tells you nothing about what to do today. PARA asks a question with a useful answer instead: how soon will I need this? Sorted by decreasing urgency, the answers fall into four groups, and browsing the first is the same act as looking at your commitments.

It also gives material somewhere to move. When a project starts, the relevant reading is pulled up into its folder; when the project ends, it drops back down. Nothing is reclassified, because commitments change and subjects do not.

The distinction people get wrong is the first two. A project has an end state you could describe and tick off; an area is a standard you maintain indefinitely. Run a half marathon in October is a project, fitness is the area it sits inside. Ship the new pricing page is a project, the website is an area. If you cannot say what would make it finished, it is an area, and treating it as a project produces a to-do that never gets crossed out.

Areas are the folder most people under-use. They hold the recurring, unglamorous material: the running notes for a one-to-one, the standard operating procedure, the household paperwork. Nothing there has a deadline, so it never surfaces on its own, which is exactly why it needs a home.

Resources is the folder that used to be your whole subject tree. It is fine for it to be the biggest and the least visited: its job is to hold things until a project needs them.

Forte's rule is to file by where it will be used, not by what it is, preferring the most actionable folder that honestly applies. Walk the list downwards and stop at the first yes:

1. Is this useful for a project I am working on right now? File it in that project.
2. If not, does it belong to an ongoing responsibility? File it in that area.
3. If not, is it a topic I want to keep? File it in resources.
4. If none of those, archive it.

The rule deserves this much precision because the decision recurs constantly and should take a second or two. If it is taking longer, the answer is Resources. A misfiled item costs almost nothing in a system with working search; a minute of deliberation, repeated forty times a week, costs you the system.

When a project ends, move the entire folder into Archives, intact. Do not dismantle it. The instinct to spend an hour redistributing the useful pieces into Resources is the instinct that kills the practice, and it is unnecessary: an archived project folder still contains everything, still turns up in search, and still makes sense as a unit because the work it belonged to did. The one exception is the piece you already know you will reuse, a template or a supplier list, which gets promoted to Resources or to the area it serves.

Areas get archived too, when they stop being yours: a job you left, a house you sold. The counter-move matters as much as the archiving. Before starting a new project, search the archive. Most of the leverage in keeping old work sits in the fifteen minutes at the start of the next one, when you find the deck or the estimate from the last time you did something similar.

Distillation in Forte's system is done in layers, each one added on a later visit rather than all at once. A note in full looks like this:

• Layer 1, the saved passage. What you captured, in the source's words, with a link back to where it came from.
• Layer 2, bolded text. On the next visit, bold the sentences that carry the point. A small fraction of the passage, not half of it; if most of it is bold, nothing is.
• Layer 3, highlighted text. The best of the bolded text, highlighted. Highlights are a subset of the bolds, which is what makes the layers nest rather than compete.
• Layer 4, an executive summary. A few bullets at the top of the note, in your own words, saying what the note is for.
• Layer 5, the remix. The material rewritten into something of yours, at which point the note has done its job.

The mechanism is a search cost. Opening a note you saved eight months ago should not require rereading it to find out whether it is relevant. Bolding and highlighting make that a two-second judgment instead of a two-minute one, and the executive summary makes it instant.

The warning matters as much as the method: most notes never need more than the first layer, and that is the design working, not failing. A layer is added when a note earns it by being opened again for a reason, never on a schedule and never while processing the inbox. Treating the five layers as a checklist recreates exactly the labour the system was meant to remove, and front-loads it onto the majority of notes you will never use. By Forte's own account, only a small minority of his notes reach the upper layers.

A second failure is worth naming because it is invisible. Bolding and highlighting are easy to do without thinking, and a note can end up looking distilled while containing no judgment at all. The test: read only the bold text, and if it does not hold together as a statement, the layer was decoration. The heavier alternative is to rewrite the idea in your own words as a self-contained note, which is what Zettelkasten and evergreen notes demand. Forte's distillation is deliberately cheaper, and correspondingly less permanent.

PARA is four folder names, so it can be implemented anywhere in about ten minutes. Forte's advice is to use the same four names in every tool you keep things in, notes app, file system, cloud drive, bookmarks, so there is one mental model rather than four.

A plain filesystem. Four directories at the top of your documents folder, number-prefixed so they sort in actionability order rather than alphabetically:

• 01 Projects/, one subfolder per active project, named for the outcome
• 02 Areas/, one subfolder per standing responsibility
• 03 Resources/, subject folders, as many as you like
• 04 Archives/, the completed and the abandoned, ideally with a year in each folder name

This version has a property none of the app-based ones do: it will still work in ten years, in any editor, with grep. If you want stable identifiers too, the usual hybrid is PARA for the names and numbers for the addressing, which is the subject of Johnny Decimal and digital gardening.

Obsidian. Two workable approaches. The literal one is four top-level folders, mirroring the filesystem. The one most experienced users end up at is a flat vault with the PARA position recorded as a property or a tag, because folders are exclusive and Obsidian's value is in links, which are not. With properties, archiving a project is one field change, and a plugin like Dataview can generate a live index of active projects rather than you maintaining a list. Do not run both: a folder tree and a tag system saying different things is worse than either.

Notion. The clean build is one database with a type property set to project, area, resource or archive, and four filtered views. Notion is the one common tool where an item can genuinely live in several places at once, through relations, so a resource can be attached to three projects without being copied. That removes PARA's single-location constraint, at the cost of a structure that is harder to move elsewhere later.

Repeating the names looks pedantic, and pays for itself the first time you look for something without wondering which tool's taxonomy you are in.

Four honest problems, three of which have fixes.

• The archive becomes a graveyard. Archives is meant to be a searched store, and the difference between that and a landfill is entirely a habit. Two things help: name archived folders with the year and the outcome (2025 Pricing page relaunch (shipped)) so a search result is legible, and make searching the archive the first step of any project kickoff. If you have never once retrieved something from Archives, you do not have an archive, you have a deletion queue with storage costs.
• Express is the step almost nobody reaches. Capture, Organize and Distill are collecting behaviours. They feel productive, and none of them requires you to have an opinion. Express is the only step that produces anything and the only one with a real cost, so it is the one that gets deferred. The diagnostic is blunt: over the last three months, what did you make that drew on your notes? If the answer is nothing, more capture will not help. Pick one thing to produce and pull material toward it.
• Filing fatigue is real. Four folders is few, but the decision recurs on every item, and decision cost is what people abandon systems over. The durable fix is to file less rather than faster: capture to an inbox with no decision at all, sort once a week, let search cover the rest. Automated classification can take the first pass, but a tool that files confidently and wrongly is worse than an inbox.
• PARA does not build connections. This one has no fix inside PARA, because it follows from the design. Folders are exclusive: a note lives in one place, and no relationship is recorded between the note in a project and the related note in resources. PARA is excellent at retrieving something you know you have and poor at showing you a connection you did not know existed. The usual answer is to keep PARA as the folder layer and add a linking layer above it, which is what LYT and maps of content describe.

One boundary is worth stating plainly rather than counting as a flaw. PARA organises material, not commitments. It will tell you where the notes for a project are; it will not tell you the next action, what is waiting on someone else, or what you agreed to and forgot. That is a task system's job, and the common pairing is Getting Things Done for the actions with PARA for the knowledge, sharing names where they overlap so the project list in one matches the project folders in the other.