Where to put things so you can find them again

The problem with most filing systems is not that they are messy. It is that they are organised by the wrong thing.

You build folders by topic. Marketing, Finance, Ideas, Research. That makes intuitive sense when you are setting the system up. But work does not arrive by topic. It arrives as projects.

You get a client brief. You start a launch. You run a campaign. All of these pull from Marketing and Finance and Ideas and Research at the same time. The topic folders do not help you find things for a specific project. They give you more places to look.

Tiago Forte identified this problem and built a better structure around it. He calls it P.A.R.A. He has written about it in depth at fortelabs.com. The original work is his. What follows is how I explain it to myself, and how I use it.

The four categories

Projects — a series of tasks with a goal and a deadline. It ends.

Areas — a sphere of ongoing activity with a standard to maintain. It does not end.

Resources — a topic of ongoing interest with no active outcome attached.

Archive — anything inactive from the other three.

Four categories. The categories are not novel. What matters is the distinction between the first two.

The distinction that does the work

A project ends. An area does not.

Running a marathon is a project. Health is an area. Publishing a book is a project. Writing is an area. Building a client onboarding system is a project. Client delivery is an area.

Most filing systems collapse these together. They store "fitness notes" alongside "marathon training plan" as if they are the same kind of thing. They are not. One has a deadline and a finish line. One does not.

When you mix them, you cannot tell how many real projects you have. You cannot close anything out. Completed projects sit in the same pile as ongoing areas and feel like they are still active. The list never shrinks.

Three things break when you cannot tell the difference

You cannot know your real workload. "Hiring" tells you nothing about capacity. "Four named projects with deadlines" tells you everything. A clear project list is a load-bearing document. Without it, you are guessing at your own schedule.

You cannot stay motivated. A list that never changes is demoralising by design. Projects complete. Something starts. Something ends. That rhythm is what makes work feel like it is moving. Areas are important. They do not give you the same closure.

You cannot see your progress. Ask anyone what they achieved last year and watch them struggle. Closed projects are the answer. They are the visible record of what actually got done.

The project list is not just an organisational tool. It is the primary record of what you have done.

Hobbies and dreams

Forte makes a distinction worth keeping.

A project with no matching goal is a hobby. A goal with no matching project is a dream. Both are fine. Neither is progress.

This is useful not because it is harsh but because it is clarifying. If you have a goal with no project attached to it, you are not working on it. You are thinking about working on it. The project is the commitment.

Look at your goal list. For each item, ask: is there an active project with tasks and a deadline? If not, it is a dream — which is fine to hold, but worth knowing.

One list, everywhere

The most important rule in practice: define your projects on paper first, before any tool.

Name them clearly. Be specific. "Agency" is not a project. "Write and publish three blog posts for Q3" is a project.

Then replicate that exact list across every app you use. Same words, same capitalisation.

This sounds like unnecessary duplication. It is not. It gives you the consistency of a central system and the adaptability of using the right tool for each context. Your project list in Notion should match your list in your notes app should match your to-do app. One glance tells you where you stand.

The moment the lists diverge, you have two systems. Two systems means cognitive overhead every time you switch context.

The four rule

Four categories wide. No more than four levels deep.

This is a constraint, not a law. Forte offers it as a limit on complexity. If your system needs a fifth category or a fifth level of nesting, the system has probably grown past the point of usefulness.

The purpose of a filing system is to make retrieval fast. Depth kills retrieval. Breadth kills it more slowly. Four by four is a useful ceiling on both.

The failure mode of each category

Every category has a way of breaking down. Knowing the failure modes makes the system easier to maintain.

Projects failure mode: projects that never get a deadline. You create a project note but never assign an end date. It lives in the active list forever, neither completed nor abandoned. The list grows. The signal value drops. The fix is simple: every project needs either a deadline or an active decision to archive it. "This is ongoing indefinitely" is an area, not a project. Move it.

Areas failure mode: areas that absorb projects. You have an "Areas/Health" folder with a marathon training plan inside it. But "run a marathon" has a finish line. It is a project. When areas absorb projects, you lose the ability to see what is active. Everything becomes ongoing. Nothing ever completes.

Resources failure mode: hoarding. Resources become a permission structure to save everything. The article that seemed important two years ago. The research you bookmarked for a project that never started. Most of it never gets retrieved. The cure is retrieval-first thinking: only save something if you can clearly state when and why you would retrieve it. If you cannot, do not save it.

Archive failure mode: not archiving. People keep completed or abandoned projects in the active folders because archiving feels final. The result is a list that grows forever and loses its signal value. The archive should be large. The active list should be short. Archiving is not failure. It is the mechanism that makes the active list trustworthy.

How I use this: Obsidian and Notion

My working reality is split across Obsidian and Notion. They do different things and they do not try to do each other's job.

Obsidian is the vault, stored at C:\Dev\knowledge\. This is where permanent notes live. Processed thinking, reference material, journal entries, post-mortems on projects that closed. It is a library. It is not a project manager. The structure inside the vault follows P.A.R.A. loosely:

• knowledge/about-me/ holds identity notes and operating context.
• knowledge/crm/ holds context notes on people I work with regularly.
• knowledge/intelligence/ holds research outputs and dated intelligence notes.
• knowledge/operational/ holds playbooks, system documentation, and reference material.
• knowledge/projects/ holds a context note per active project — what it is, what the goal is, and what decisions I have made. Not the code. Not the task list. Just the decisions, constraints, and goals.

Notion is the active layer. Current projects with real deadlines. CRM pipeline. Running documents I need to access quickly. The things that need to move.

The code lives in C:\Dev\projects\active\. The notes live in the vault. The tasks live in Notion. None of these tries to hold all three.

The crossing point is what makes the system work. When a project closes, the key decisions and outputs get written up in Obsidian under the relevant area or resource. The Notion board gets archived. The code moves to projects/archive/. Three things close in three places. Nothing lingers in the active layer.

Where it is messy

The honest version: knowledge/operational/ has become a catch-all. Reference material that should be in Resources keeps ending up there because it is "ongoing enough." The distinction between Areas (things with a standard to maintain) and Resources (topics of interest with no active outcome) gets blurry at the edges. I have not fully resolved it.

The project list is also more consistent in Notion than in Obsidian. The vault project notes sometimes lag behind the Notion project status. A project that was archived in Notion six weeks ago may still have a note in knowledge/projects/ that says "active." This is the most common maintenance failure in my system. The fix is the weekly review.

The review cadence

The system breaks without regular review. P.A.R.A. is not a set-and-forget structure. It is a living list that requires maintenance.

Weekly (ten minutes): Scan the project list. Is everything on it still active? Are any deadlines approaching that are not on my calendar? Is there anything that should be archived this week? This is not a planning session. It is a signal check. The list should match reality. If it does not, fix it here.

Monthly (thirty minutes): Review the areas. Is anything in Areas that should be a project with a deadline I have been avoiding assigning? Is anything in Resources that I have never retrieved and probably never will? Is the archive growing in a useful direction, or is it a graveyard of things I never finished?

The review is not about the system. It is about the project list. The project list is the unit of truth. The rest of P.A.R.A. exists to support it.

A list you trust is the only kind worth maintaining. The system earns that trust through regular, honest updates. Skip the review for two months and the list becomes noise.

Want this wired into your business, not just your notes? Book a 30-min AI discovery call and we'll map it out.