Evergreen notes: why yours stopped being evergreen

You wrote a handful of genuinely good evergreen notes a year ago. Atomic, in your own words, linked to three or four related ideas. It felt like the moment your thinking finally started to compound. Open that folder now. Most of those notes have not changed a single character since the day you wrote them.

That is the quiet contradiction at the heart of the method. Evergreen notes are defined by the one thing almost nobody actually does to them: keep them evolving. The name promises a note that stays alive. What you usually get is a note that was alive for one afternoon and has been sitting still ever since, slowly drifting out of date while you assume it is still good.

This is not an argument against evergreen notes. The idea is one of the best things to come out of personal knowledge management. It is an argument that the method is only half a method, and the missing half is the reason your collection feels more like a museum than a garden.

What are evergreen notes?

Evergreen notes are notes written and organized to evolve, accumulate, and build understanding over time, rather than sit as a one-time record of what you read or thought. The term comes from developer and researcher Andy Matuschak, who framed them around four principles.

They should be atomic: one idea per note, so it can be reused and linked cleanly. They should be concept-oriented: titled and filed by idea ("Retrieval builds memory") rather than by source or date. They should be densely linked: connected to related notes so your knowledge forms a web instead of a pile. And they should be evolving: revised and expanded as your understanding grows.

Maggie Appleton, who did as much as anyone to popularize the approach, describes it in Growing the Evergreens as a system that "aspires towards cumulative personal knowledge, rather than simply information capture." That word, cumulative, is the whole promise. A good evergreen note is not a snapshot. It is a living statement of your best current thinking on one thing, and it is supposed to get better every time you touch it.

The first three principles are about how you write the note. The fourth is about what happens after, and it is the one that quietly decides whether any of this works. If you want to skip the theory and just have the evolving handled for you, you can start free and come back to the argument.

Evergreen notes vs. permanent notes: the zettelkasten question

People coming from the zettelkasten world constantly ask how evergreen notes differ from permanent notes, and the answer is exactly where the trouble hides.

In a classic zettelkasten, a permanent note in a zettelkasten is finished. Niklas Luhmann's slip-box treated a permanent note as a fixed atom: once you filed it, you did not rewrite it, you wrote a new note that responded to it. The system grew by accretion, not revision. That contract is also why permanent notes stop being true once the claims inside them come from a world that keeps moving.

Evergreen notes deliberately break that rule. They are fluid. The same note is meant to be reopened, rewritten, and deepened across months and projects, so the note you have on "spaced repetition" in 2026 is a richer version of the one you started in 2024.

That fluidity is the feature. It is also the liability. The Obsidian community tends to summarize the distinction as permanent notes being fixed once filed and evergreen notes being living objects that change alongside your understanding. A permanent note is designed to be correct on the day you write it and then left alone, so staleness is baked into the contract and you know not to trust an old one blindly. An evergreen note makes the opposite promise. It says "this is my current thinking, kept current." When you stop keeping it current, and you will, the note keeps making that promise anyway. It looks maintained. It is not.

The principle everyone quotes and nobody keeps

Here is the honest version of how to take evergreen notes, based on how it actually goes. You learn the four principles. You write atomic, concept-oriented, densely linked notes. You feel great. And then the fourth principle, evolving, turns out to require something the first three never warned you about: coming back.

Coming back does not scale on willpower. Revisiting an old note has no trigger. Nothing tells you that the note you wrote on a web framework's auth pattern is now describing a deprecated approach, because the framework shipped a major version and you were not looking. Nothing flags that the study your note summarized was later corrected. Nothing notices that four of the note's links now 404. The note sits in your densely linked graph looking authoritative, and it is quietly, confidently wrong.

This is knowledge decay, and it hits evergreen notes harder than almost any other format precisely because they promise the opposite. A messy daily journal never claimed to be current. An evergreen note did.

Consider a concrete evergreen notes example. A developer keeps a beautifully atomic note titled "Prefer server-side session validation for auth." It cites a framework's docs, links to three related security notes, reads like a distilled principle. Six months later the framework deprecates that middleware order. The note does not change. It is now teaching the developer a pattern that will fail in code review, and because it is an evergreen note, they trust it more than a random old bookmark. The format's authority has become a bug. This is also why a stale atomic note is more dangerous than a stale messy one: the cleaner the note, the less it shows its age.

This is the gap every PKM method leaves open. Capture, organize, connect, and then, in every framework from zettelkasten to PARA to tending a digital garden, the instructions trail off right where maintenance should begin. Evergreen notes name the maintenance step out loud and still hand it to your future self as unpaid manual labor.

What an evergreen note needs to actually stay green

Strip away the tooling and the maintenance an evergreen note needs is not complicated. It needs three things done to it, repeatedly, forever.

It needs to be resurfaced. A note you never see again cannot evolve, so something has to bring the right note back to your attention at the right moment, by relevance to what you are working on now, not just because you went looking.

It needs to be re-checked against the world. The claims in a concept note point at things outside the note: a framework version, a statistic, a source, a link. Those move. Keeping the note green means periodically comparing what it says to what is currently true, and seeing the difference.

And it needs to be re-linked as the graph grows. A note written when you had 80 notes is under-connected once you have 400. The dense-linking principle is not a one-time act at creation; it decays too, as new adjacent ideas arrive that the old note never got wired to.

None of this is hard. It is just relentless, and relentless is exactly what humans are bad at and software is good at. The reason your evergreen notes stopped evolving is not that you are undisciplined. It is that you were asked to be a cron job. You can hand that job to something built for it and see your first diff.

How to keep evergreen notes evergreen, in practice

This is the part Matuschak's principles leave to you, and it is the part Scribelet is built to take off your hands. The idea is simple: if a note is supposed to evolve, let the evolving run in the background instead of depending on you remembering to do it.

Background verification checks a note's factual claims against the web on a schedule you set, then shows you a diff: green for what is new, red for what is now outdated, with the source. You review, accept or dismiss, and the note updates. That is the "evolving" principle turned into an actual event that arrives, rather than a virtue you have to summon. The auth-pattern note surfaces the day the framework deprecates it, not the day it breaks production.

An auto-linker watches your growing note graph and suggests connections the note did not have when you wrote it, so dense linking keeps up with the collection instead of freezing at creation. A stale checker flags evergreen notes that relate to your recent work but have not been touched in months, which is the resurfacing trigger the method never gave you. If you would rather run the cadence by hand, a thirty-minute weekly review does the same job manually, and the background version does it while you are busy writing the next note.

Because this is AI touching your notes, control matters. Scribelet works out of the box, and bringing your own OpenAI, Anthropic, or Gemini key is an optional path if you want your notes checked by the provider you choose rather than one we picked for you. Either way you see every change as a diff before it lands. Evolving your notes should not mean handing them to a black box.

Evergreen note methods, compared

Every approach to evergreen notes gets you a well-written note. The difference shows up a year later, in whether that note is still connected and still true.

The first three rows are where nearly every guide on the method stops. The last row is the difference between a note that says it is evergreen and a note that stays that way.

An evergreen note is a promise to your future self

The reason your evergreen notes stopped being evergreen is not a discipline failure. It is that the method gave you four principles and only helped you with three, then quietly assumed you would perform the fourth by hand, on no schedule, forever. Nobody does that. The notes drift, the links rot, and the format's own authority turns your best old thinking into confident misinformation.

An evergreen note is a promise that this idea will still be your current, accurate thinking when you reach for it next year. Keep the promise with maintenance, not willpower. Write the note atomic and linked, and then let a system resurface it, re-check it, and re-link it so the version you find later is still the version that was true. Keep your evergreen notes actually evergreen.