Skip to content

The PARA method has no maintenance step

Scribelet Team
9 min read

A year ago you set up PARA. Four folders, one clean decision tree, and for a few weeks it felt like your digital life finally had a shape. Projects for what you're working on, Areas for what you maintain, Resources for what might matter later, Archives for what's done. Every note had a home. And it was meant to hold everything, not just your job, because the parts of your life that aren't work generate just as much to keep track of.

Open that system today. Projects still looks alive. Areas is mostly current. But Resources has become a drawer you're afraid to open, full of notes that were accurate the day you filed them, and Archives is worse: a sealed room of things you decided were finished and never looked at again. The PARA method told you exactly where to put each note. It never told you which of those notes stopped being true.

This is the quiet flaw in the most popular organizing system in personal knowledge management, and it has nothing to do with the four categories being wrong. They're good categories. The problem is that PARA is a system for deciding where a note goes, and there is no step for deciding whether a filed note is still worth trusting. This piece walks through what PARA does well, where it breaks down over months, and what a note-taking setup looks like when maintenance is built in instead of assumed.

What is the PARA method?

The PARA method is a system for organizing digital information into four categories by how actionable it is: Projects (short-term efforts with a goal), Areas (ongoing responsibilities), Resources (topics of future interest), and Archives (inactive items). It was created by Tiago Forte and popularized through his book Building a Second Brain.

The appeal is real. Most organizing schemes sort by topic, which forces you to invent a taxonomy and then fight it forever. PARA sorts by actionability instead, which maps to how you actually work: things you're doing now, things you tend, things you might need, things you're done with. You use the same four buckets across every tool, so a note, a file, and a task all follow one rule. Forte lays out the full framework on his blog, and it deserves its reputation as the fastest way to go from chaos to a workable structure.

But look closely at what those four categories describe. Every one of them is a statement about placement. Where does this belong right now? None of them is a statement about accuracy. Is this still correct? PARA is a brilliant answer to the first question and silent on the second, and over a long enough timeline the second question is the one that costs you.

PARA is a filing system, not a maintenance system

Here is the assumption baked into every PARA tutorial: a note's value is fixed once you file it correctly. Put it in the right bucket and the job is done. That assumption holds for a physical filing cabinet, where a document is a frozen artifact. It does not hold for the kind of notes knowledge workers actually keep.

Your notes reference a moving world. The API you documented ships a breaking change. The pricing you saved from a competitor goes up. The onboarding process you wrote down gets three new steps. The paper you cited gets a correction.

None of that changes where the note lives in PARA. The note sits exactly where you filed it, looking as authoritative as the day you wrote it, while the thing it describes drifts out from under it. This is knowledge decay, and a filing system is structurally blind to it, because filing is a one-time act and decay is a continuous one.

That blind spot is not unique to PARA. It's the same gap we've written about across every popular method: they all optimize the moment of capture and organization, and then none of them include a maintenance phase. PARA just makes the gap especially visible, because its whole promise is a place for everything. A place for everything, and no mechanism to check whether the things in those places are still true.

If you want the short version of the fix before the long one: Scribelet's free plan keeps the four-bucket structure you already like and adds the checking step PARA leaves out. The rest of this explains why that step matters and how it works.

The PARA method's four buckets (Projects, Areas, Resources, Archives) decay at different rates, and the missing maintenance step checks whether each note is still true

Where PARA quietly breaks: Resources and Archives

Projects and Areas mostly take care of themselves, because you touch them. An active project gets revisited constantly, so a wrong note in it surfaces fast. An area you maintain gets the same attention by definition. The decay problem concentrates in the two buckets you stop looking at.

Resources is the first casualty. It's the catch-all for "interesting, might need it," which means it accumulates faster than anything else and gets reviewed least. A year in, Resources is where you saved the deployment steps, the tax rule, the framework comparison, the vendor's rate card. Every one of those was a snapshot of a moment. Half of them have moved. You won't find out which half until you reach for one under pressure and build on information that expired six months ago.

Archives is the more insidious one, because PARA actively encourages you to forget it. The entire point of the Archive is to get inactive things out of sight so your workspace stays clean, and that's genuinely useful for focus. But "out of sight" and "no longer true" are a dangerous pair.

A project you archived as complete leaves behind notes, decisions, and references. When a similar project starts, you pull those archived notes back into active use, trusting them precisely because they represent finished, settled work. That's exactly when their age bites. The Archive is where accurate notes go to quietly rot, and PARA's design guarantees you won't notice until you've already relied on one.

PARA vs Zettelkasten: two methods, one blind spot

People often frame this as a choice. PARA organizes by actionability; the Zettelkasten method organizes by connection, linking atomic notes into a web of ideas. Sönke Ahrens made the case for the latter in How to Take Smart Notes, and the two camps argue about which structure produces better thinking.

The argument misses what they have in common. Both are systems for arranging notes, and neither has anything to say about keeping the content of those notes correct over time. A Zettelkasten with a dense, beautiful link graph can be a dense, beautiful graph of outdated claims. A PARA system with perfect bucket discipline can be perfectly organized misinformation. Structure is orthogonal to accuracy. You can have flawless organization and still be reading something false, because organization tells you where a note is, not whether it holds up.

That's the reframe worth carrying: the method you pick decides how your notes are shaped, not whether they stay true. Shape is a one-time design decision. Truth is an ongoing maintenance problem, and every method on the market leaves it to you.

What a self-maintaining PARA system looks like

Start with the principle, not the product. A note system that fights decay has to do something no filing method does: revisit its own contents on a schedule and tell you when reality has moved. Not reorganize them. Re-check them. The buckets can stay exactly as PARA designed them. What changes is that something is watching the notes inside them.

In Scribelet, that watching is background verification. On a schedule you set, it searches the web, compares what it finds to what a note claims, and hands you a diff: green for new information, red for what no longer holds. You review it, accept or dismiss, and the note updates. The Resources drawer stops being a place things go to expire, because the expiring ones raise their hand. The Archive stops being a sealed room, because a note you pull back into active work gets checked before you build on it. This is the same maintenance discipline behind a working AI second brain, applied to the buckets you already sorted.

Here is how the four categories change when maintenance is part of the system rather than an afterthought you never get to.

PARA bucketWhat PARA doesWhat decays over timeWhat a maintenance layer adds
ProjectsHolds active, goal-bound workLittle; you touch it constantlyAuto-links related notes as the project grows
AreasHolds ongoing responsibilitiesSlowly; standards and contacts shiftFlags a note when its facts change
ResourcesCatch-all for future referenceFast; snapshots go stale unreviewedScheduled checks surface what expired
ArchivesStores finished, inactive itemsSilently; nobody rereads itRe-verifies a note before you reuse it

Read the last column top to bottom and it describes the step PARA is missing across all four buckets: not a better place to put the note, but a way to know the note is still worth having. None of this asks you to abandon PARA. It asks the system to do the part of the job the method quietly handed back to you.

The honest caveat: verification helps most for notes that reference an external, checkable world. A note documenting a library's API, a market rate, a policy, or a process gets real value from it. A private journal entry or a rough idea does not need fact-checking, and the system leaves those alone. Maintenance is for the notes whose truth lives outside your head.

PARA across every device and every tool

Forte's original pitch for PARA is that you run the same four buckets everywhere: your files, your tasks, your notes, all under one structure. That consistency only pays off if the notes themselves are consistent across devices, which is its own quiet failure point. A note that's stale on your laptop is stale on your phone the moment it syncs, faithfully copied to every screen you own.

So the tool you run PARA in matters more than the tutorials admit. It should keep the structure identical on every device you use, sync without losing edits, and run the maintenance checks regardless of where you opened the note. PARA gives you one organizing rule; the app should give you one accurate copy of each note under that rule, not five copies of the same expired snapshot.

Try the version of PARA that checks itself. Keep Projects, Areas, Resources, and Archives exactly as you like them, and let background verification handle the part the method skips. Get set up in a few minutes.

Is the PARA method worth it?

Yes, with one adjustment. As a way to decide where a note, file, or task belongs, PARA is close to the best system there is: fast to learn, flexible across tools, and free of the taxonomy wars that sink topic-based schemes. If you have no structure today, adopting PARA is a clear upgrade and you should do it.

Just don't mistake it for a complete knowledge system. PARA is the placement half, and what a PKM system actually needs is a maintenance half to go with it. It answers "where does this go?" and stops, and it was never designed to answer "is this still true?" Treat that second question as your responsibility, and either run a periodic review of your own Resources and Archives by hand, or use a tool that runs the check for you. The method plus a maintenance habit beats the method alone, every time.

The bucket PARA forgot

PARA divides everything you know into four categories, and there's a fifth idea it left out that matters more than any of them: whether the note in the bucket is still accurate. Organization was the hard problem a decade ago. It's a solved problem now, and PARA solves it well. The unsolved problem is decay, and no amount of clean filing touches it.

So keep the four buckets. They earned their place. Then add the step they assume you'll do yourself and almost never do: check that what you filed is still worth trusting. Start writing with a system that keeps your notes accurate, not just organized. Try Scribelet free.

Share this article

We use cookies for analytics to improve your experience. Learn more