Skip to main content

The Half-Life of Notes: Why Your Second Brain Decays and What to Do About It

· 16 min read

Most second brains are built with ambition and abandoned with silence.

The pattern is familiar. You discover a note-taking system — Obsidian, Notion, Logseq, a folder of Markdown files. You read about Zettelkasten, PARA, or evergreen notes. You capture diligently for weeks or months. The system fills up. It feels productive.

Then, somewhere around month six, you notice something. You open a note from three months ago and realize you no longer know what it means. The context has evaporated. The source link is dead. The half-formed thought it captured is no longer half-formed — it is just dead.

The system did not fail because you stopped adding to it. It failed because notes have a half-life, and most knowledge systems are designed for accumulation, not maintenance.

This essay is about knowledge entropy — the quiet forces that cause personal knowledge systems to lose value over time — and the deliberate practices that keep a system alive across years, not months.

The accumulation trap​

Most advice about second brains focuses on capture. Capture everything. Build the habit. Don't worry about organization yet. You will figure it out later.

This advice is not wrong. Capture is necessary. Without capture, there is nothing to maintain. But it creates a dangerous asymmetry: capture is easy, maintenance is hard, and the gap between them compounds over time.

Consider a real trajectory. In month one, you have fifty notes. All of them are fresh. You remember writing them. The context is still in your working memory. Organization does not matter much because you can find things by browsing or searching for keywords you remember.

In month six, you have four hundred notes. You do not remember writing most of them. Some were captured in a context you have since left — a project that ended, a topic you stopped pursuing, a line of inquiry that turned out to be a dead end. The notes are still there, but they have become noise. Every search returns irrelevant results. Every browse reveals abandoned fragments.

In month twelve, you have eight hundred notes. Now the problem is structural. The system is dense with dead material. Finding a useful note is harder than writing a new one. The second brain has become a graveyard — full of artifacts, empty of signal.

The accumulation trap is this: adding notes feels like progress, but every new note makes the system slightly harder to maintain. At some threshold, the cost of maintenance exceeds the value of retrieval, and the system stops being used.

The five forces of knowledge entropy​

Knowledge systems do not decay randomly. They decay through specific, predictable mechanisms. Understanding these mechanisms is the first step toward designing against them.

Force 1: Context evaporation​

A note captures content — words, links, quotes, data. It does not capture the full context that made that content meaningful when you saved it.

You read something. You had a reaction. You saved it thinking the reaction would be obvious later. It is not. A month passes, and the note says "Interesting — check against Q2 numbers" without telling you what was interesting, what the Q2 numbers were, or why the comparison mattered.

Context evaporates because human memory is associative and reconstructs itself constantly. The cues that would have triggered recall at the time of capture are gone. The note sits there, formally intact but functionally dead.

Standard note-taking advice says to add a sentence of context to every capture. But this advice underestimates how much context matters. A sentence is rarely enough. The context that makes a note useful later is the context you are least likely to write down — because at the moment of capture, it feels too obvious to need documentation.

Many notes are anchored to external sources — URLs, PDFs, screenshots, API responses, database exports. Over time, those sources degrade.

The URL goes dead or the content changes. The PDF is renamed or moved. The screenshot was saved in a folder you no longer use. The API response is stale because the endpoint changed. The database export is from a schema that no longer exists.

Link rot is well-studied for the public web. A 2021 study by Harvard Law School and the New York Times found that roughly 25% of links in New York Times articles were broken, and the rot rate increased with age (Harvard Law Today, "Link Rot" study). Personal knowledge systems face the same problem, compounded by sources that were never public to begin with — internal documents, Slack messages, Notion pages shared within a team, and temporary file hosts.

Every note with a dead source loses a layer of trustworthiness. You cannot verify it. You cannot refresh it. It becomes a claim without evidence.

Force 3: Proprietary format drift​

A note written in an app that changes its data format, deprecates features, or shuts down is a note you may not be able to read in five years.

Proprietary note-taking tools are especially vulnerable. Notion pages are stored in a proprietary database. Evernote uses its own format. Even Obsidian, which stores plain Markdown, uses plugin-specific syntax that may not be portable.

Less dramatically but more commonly: the tool you use to capture today may not be the tool you use to read tomorrow. Notes captured in Apple Notes are hard to migrate. Notes captured in a reading app like Readwise may not survive a subscription lapse.

Format drift is slow. You do not notice it until you need a note from three years ago and discover it is effectively locked in a format you no longer use.

Force 4: Classification decay​

Every organizational system is a bet about what categories will matter in the future.

Folders, tags, and MOC (map of content) structures encode assumptions about your intellectual priorities. When those priorities shift — and they will — the structure becomes misaligned.

A note tagged #startup-ideas in 2023 sits beside a note tagged #gpt-platform-comparison in 2026. The tags reflect who you were, not who you are. The browsing structure that once felt intuitive now feels alien. Navigating your own system becomes a exercise in remembering your past self.

Classification decay is especially dangerous because it is invisible from inside the system. You do not notice the misalignment because you have adapted to it. But a new idea that does not fit the old structure may simply not get captured — or worse, get crammed into a category that distorts it.

Force 5: Semantic drift​

Notes change meaning as your understanding changes.

A note that once read as a deep insight now reads as obvious. A note that once felt important now feels trivial. A note that captured a tentative hypothesis now looks like it captured a settled conclusion — because you forgot the tentativeness.

Semantic drift is the subtlest force of entropy because the note itself does not change. Its relationship to your current knowledge changes. Without explicit indicators — date stamps, confidence marks, context notes — the note appears to say something it does not say, or means something it no longer means.

This is particularly dangerous for notes used as decision records. If a note says "Platform X has reliable payouts" from January, and you read it in June without checking the date, you are making a June decision on January data. The note did not decay. Its relationship to reality did.

Why search does not fix this​

A common counterargument: this is why you use search. If your notes are full-text searchable, you do not need careful organization. You search for what you need when you need it.

This argument works for small systems and falls apart for large ones.

Full-text search has no concept of context freshness, source validity, or semantic accuracy. Searching for "platform payout reliability" returns every note containing those words, regardless of whether the note is from last week or last year, from a verified source or a rumor, from a current project or an abandoned one.

Search returns presence, not relevance. As the system grows, every query returns more results, many of them from the decaying tail. The signal-to-noise ratio drops. Eventually, the cost of filtering search results exceeds the cost of redoing the research from scratch.

The system that relies on search alone is a system that is only useful for retrieving what you already know exists. It fails at surfacing what you need to rediscover.

The maintenance practices that actually work​

The forces of entropy are not stoppable. Context will evaporate. Links will rot. Classifications will decay. The goal is not to prevent decay. The goal is to design a system where maintenance is built into the workflow — not bolted on as a chore.

Practice 1: Write notes for your future self, not your present self​

This is the single highest-leverage change.

When you capture a note, assume that the person reading it six months from now remembers nothing about the context in which it was written. That person is you, with amnesia.

A useful note answers at minimum:

  • What is this? (one sentence)
  • Why did I save it? (the motivation, not just the content)
  • What should I do with it? (read, act, connect, archive)
  • When did I capture it? (date stamp)

The act of writing these four things adds perhaps thirty seconds to capture. It saves minutes or hours of confusion later. More importantly, it forces the present self to be explicit about why the note matters — which often reveals that it does not matter enough to save at all.

Practice 2: Maintain a discard habit​

The most underrated skill in knowledge management is deletion.

Not every note deserves to live forever. Most notes are scaffolding — they served a purpose during a project or a learning phase, and that purpose is complete. Keeping them adds noise without adding signal.

The discard habit is simple: when you encounter a note in the course of normal work and realize it no longer serves you, delete it. Do not archive it. Do not tag it for later review. Delete it.

If you are uncomfortable with deletion, ask: would I recreate this note from scratch if I needed it? If the answer is no, the note is not valuable. If the answer is yes, ask: would finding this note among eight hundred others save me more time than recreating it? Often the answer is still no.

A knowledge system gets better when it gets smaller, not just when it gets bigger.

Practice 3: Schedule light-touch reviews by age cohort​

Heavy review systems — like the full Zettelkasten review or the GTD weekly review — are aspirational and brittle. Most people stop doing them after a few weeks.

A lighter alternative: review notes by age cohort. Once a month, look at notes from the same month one year ago. Not every note. A representative sample of ten or twenty. The goal is not to process every old note. It is to stay in contact with your past thinking, spot classification decay, and notice notes that have become misleading.

A monthly fifteen-minute browse of year-old notes catches most of the silent decay. It also surfaces useful connections that were invisible at the time of capture — patterns you could not see until you had distance.

Practice 4: Use plain Markdown and local files​

This is a structural defense against format drift.

Plain Markdown files — stored locally, versioned with Git, readable by any text editor — will still be readable in twenty years. Proprietary formats may not be.

The trade-off is real: plain Markdown is less feature-rich than Notion databases, Tana supertags, or Obsidian Canvas. Some workflows genuinely benefit from those features. But every proprietary feature is a dependency. When the tool changes or disappears, the notes that depend on that feature lose structure.

A practical compromise: use tools with proprietary features for capture and working memory. Export durable notes to plain Markdown files for long-term storage. The working system can be feature-rich. The archive should be boring.

Practice 5: Separate working notes from durable notes​

Not all notes deserve the same maintenance investment.

Working notes are notes in active use — project plans, current research, ongoing analysis. They change frequently. They need high maintenance. They live near the surface of the system.

Durable notes are notes that have stabilized — completed research, reference material, frameworks, decision records. They change rarely. They need low maintenance. They live deeper in the system.

The problem is when the boundary blurs. Working notes get abandoned without being either discarded or promoted to durable. They sit in limbo — not useful, not deletable, just occupying space.

The fix: give every note an explicit status. Active, stable, or archived. When a project ends, move its notes to stable or delete them. Do not let them linger in a state of undeclared abandonment.

Practice 6: Version your notes with Git​

Git is not just for code. It is the most durable version-control system ever built, and it works perfectly for Markdown notes.

Versioning your vault with Git gives you:

  • A complete history of every change to every note.
  • The ability to see what a note looked like at any point in time.
  • Protection against accidental deletion or corruption.
  • A natural audit trail for decision records — when was a conclusion added? When was data updated? What was the reasoning at each stage?

Git also enforces a useful discipline: every commit requires a message. Writing a commit message forces you to articulate what changed and why, even briefly. That discipline alone reduces semantic drift.

The site you are reading​

The site you are reading now — this blog — is built from a Git-versioned vault of Markdown files. Every post you see is a plain .md file with YAML frontmatter. The build system is a static site generator that reads those files directly. There is no database. No CMS. No proprietary format between the notes and the published output.

This is not an accident. It is the same principle applied at publication scale: plain files, version control, and a workflow that makes maintenance visible. When a post needs updating, the edit is a commit. When a post is retired, the retirement is a commit. The history of every public artifact is preserved in the repository.

The same principle works for private notes. The simpler the storage format, the longer the system survives.

What kind of system are you building?​

There is a question worth asking at the start — or at any point along the way: am I building a system for today, or a system for ten years?

A system for today optimizes for capture speed, rich features, and low friction. It uses the most convenient tool available. It does not worry about link rot or format drift. It is optimized for the present moment.

A system for ten years optimizes for durability, portability, and maintainability. It uses plain formats. It has explicit status categories. It has a discard habit. It is versioned and reviewed. It is optimized for the future self who will need it most.

Most people start building a system for ten years and drift into building a system for today. The drift is invisible because it happens one note at a time. One capture shortcut. One proprietary feature. One abandoned review cycle.

The fix is not to reject convenience. It is to be honest about the trade-off and build deliberate bridges between the two modes. Capture quickly in whatever tool is at hand. Export the keepers to plain files. Review periodically. Discard aggressively. Version everything.

A second brain is not a storage device. It is a living system. Living systems need tending. The tending is the point.

FAQ​

How often should I review old notes?​

Light-touch reviews — browsing a sample of year-old notes — should happen monthly and take no more than fifteen minutes. Deep reviews — restructuring, reclassifying, major deletions — should happen quarterly or when you feel the system becoming difficult to use. The key is consistency over intensity. A monthly habit that survives is better than a weekly habit that lasts three weeks.

What do I do with notes from abandoned projects?​

Delete most of them. Keep the ones that contain reusable frameworks, non-obvious insights, or decision records that might inform future work. If a note would require more than two minutes of context reconstruction to be useful again, it is probably not worth keeping.

Should I archive or delete?​

Delete unless you have a specific reason to archive. Archiving feels safer — the note is still there if you need it — but archives tend to grow without bound and impose the same search noise as kept notes. If you are not confident enough to delete, archive with a review date. If the review date passes and you have not needed the note, delete it.

Is plain Markdown really enough for complex knowledge work?​

It depends on what you mean by complex. If your workflow depends on database relations, structured queries, or visual canvases, plain Markdown will feel limiting. But most knowledge work — reading, synthesizing, writing, connecting — does not require sophisticated features. It requires clear notes, reliable retrieval, and a maintenance rhythm. Plain Markdown plus search and internal links covers most of what most people actually do.

How does AI change knowledge maintenance?​

In both directions. AI makes capture easier — you can dump raw transcripts, summaries, and extracted highlights without friction. But easier capture accelerates the accumulation trap. More notes, faster, with less human attention per note — the system fills up with low-context material that is harder to maintain. AI also makes maintenance easier — it can help classify, summarize, and surface stale notes. The net effect depends on whether the capture or maintenance side gets more attention. Right now, capture tools are far ahead.

Related reading on this site: