Skip to content

What to Keep: Collecting Is Not a Knowledge Base

Oct 22, 20261 min
TL;DRTo decide whether to keep something, ask three questions in order: can I name a concrete use for it, can I find it again later, can I write one sentence of my own about it. No use, don't keep it; if the original is findable again keep only a link, otherwise save a copy; only items with that sentence go into the knowledge base, the rest go on a to-read list. Empty the inbox every week. The reason behind it: every keep-or-skip decision risks two errors, keeping too much buries what matters and keeping too little means searching again, and loosening or tightening your threshold only trades one error for the other.

Look up & save

Loading dictionary…

🌏 中文版

Open your bookmarks, your read-later list, or that "to read" database in Notion. When did you last take something out of it and use it? An MIT research team built List-it, a note-taking tool that lives in a browser sidebar, and analyzed the 60,000-plus notes left by 420 of its users. Only about a fifth were ever retrieved through search (Van Kleek et al. 2011). That figure counts only search, not notes people simply saw in the sidebar, so it doesn't mean the rest were useless. But it is a reminder that most of what we save never gets deliberately looked up again.

This is the first post in the personal part of Building Knowledge Bases. The overview set out four questions every knowledge base has to answer: what to keep, how to organize it, how it gets found and who maintains it. This post covers only the first. Categories wait for order 2 and linking notes for order 3, with tools and long-term maintenance in orders 4 and 5. By the end you will have a three-step test that tells you whether each item goes into your knowledge base, gets kept as a link only, goes on a to-read list, or gets deleted, and you will know how often to clear your inbox.

Saved is not read

In 2014 zettelkasten.de, a site that promotes the Zettelkasten note-taking method, gave this a name: The Collector's Fallacy. The author argues that saving feels like a reward in itself, so we keep doing it, even though knowing that something exists is not the same as understanding it:

Why fallacy? Because 'to know about something' isn't the same as 'knowing something'.

He cites Umberto Eco's How to Write a Thesis on photocopying: students copy a stack of texts and come away with the illusion of having read them. Bookmarks work the same way. There is research to go with the claim: during an office move at AT&T Labs, Whittaker and Hirschberg surveyed employees about their paper files, and employees estimated that 15% had never been read.

Keep or skip, you can be wrong either way

Keeping something you never use is one error; failing to keep something you later need is the other. In 2004 the information scientist William Jones framed the decision as a signal-detection problem, using the theory first developed for radar operators: each time you meet a piece of information, you are judging whether it is signal or noise.

Turns out usefulTurns out useless
KeptHitFalse positive: more clutter, good items more easily buried
Not keptMiss: time spent finding it again, or it can't be found at allCorrect rejection

The most useful point in the framework is that the two errors pull against each other:

The likelihood of a false positive is reduced only by increasing the likelihood of a miss, and vice versa.

Loosen or tighten the threshold and one error goes down while the other goes up. "Save everything" chooses false positives; "save as little as possible" chooses misses. The only way to reduce both is to discriminate better: to know more clearly, at the moment of saving, how the item will be used. The three-step test below is a way to practice exactly that.

Jones's colleague Bruce extended the framework in 2005 and argued that people usually lean toward keeping too much: while information is in hand we overrate it, and the costs of a false positive (more clutter, good information buried) are hard to see. That is a theoretical argument, and people vary. In a 2019 survey of UK office workers, the top reason for not deleting email was that it "may come in useful in the future" (Neave et al. 2019); but among List-it users, the largest group were people who deleted notes soon after writing them.

So rather than assume "everyone keeps too much", check yourself. Look back over what you saved in the past month and count how many items you saved and how many you went back to. My rule of thumb: if you used fewer than one in ten, you probably lean toward keeping too much, and the first step below can be strict. If you often look for something and find you never saved it, you probably lean toward missing things, and in the second step you can keep more copies.

The inbox: defer the decision, but come back

At the moment of saving, you often can't tell. A common practice is to defer: drop things into an inbox and decide later.

A 2026 study at the University of Zurich gave 29 participants, mostly students and IT professionals, a browser extension that let them drop web pages of uncertain future use into an unsorted holding area (Rutishauser & Fritz 2026). Over a study period that averaged about two weeks, 57% of the pages in the holding area were taken out and dealt with again, mostly deleted, with a smaller share moved into proper groups. The other 43% weren't dealt with during that time.

Deferring only works if you come back. When Malone looked at desk piles in 1983, he saw that a pile nobody clears defeats itself: the bigger it gets, the harder things are to find, and the reminders get buried under newer arrivals. Sorting too early may have a cost too. Whittaker and Hirschberg found that people who kept clear desks and filed their papers kept nearly twice as much as those who piled things up, yet had looked at a smaller share of it in the past year. One explanation they offer is "premature filing": filing before an item's value is known, finding out later that it was useless, and then finding it hard to throw away because of the effort that went into filing it. So when you clear the inbox, decide only whether each item stays or goes; don't rush to sort it.

How often? Method books mostly say once a week. The second step of the GTD Weekly Review is getting the inbox to zero; Tiago Forte says he clears his weekly, processing 10 to 20 items in a few minutes; zettelkasten.de suggests something tighter: when starting out, collect for an hour, stop, process what you collected before the next round, and adjust the time to suit you later. Weekly is these authors' experience rather than the result of an experiment, but it is a reasonable place to start.

Keep two places separate. The inbox holds things you haven't decided about yet, and it gets emptied every week. The to-read list holds things you have decided to read but haven't read yet. It doesn't need to be empty, but it needs a limit; for example, anything unread after two weeks gets deleted. Once you have read something, it moves into the knowledge base if you can write the sentence, and gets deleted if you can't. Mix the two and the inbox never empties.

The three-step test

When you clear the inbox, ask three questions of each item, in order: step 1 decides whether to keep it at all, step 2 decides how to keep the original, step 3 decides whether the item goes into the knowledge base or onto the to-read list. You can also ask them at the moment of saving. Forte's approach is to save on instinct, keeping anything that resonates; new items go into the inbox, and once a week he decides where they belong.

Step 1: Can I name a concrete use for it? Concrete means a project, a piece of work you have on hand, or a question you are actively thinking about. When Forte clears his inbox he asks in order: which project is this useful for? Which area of ongoing responsibility? Which topic of interest does it belong to? If all three draw a blank, he archives it or doesn't save it at all. This post is stricter than Forte and counts only the first two: "this topic is interesting" is curiosity, not a use, and you can read it for the pleasure of it and move on. Once clearing your inbox every week has become a habit, you can loosen up the way Forte does. If you can't name a use, don't keep it.

Step 2: Can I find it again later? Bruce, Jones and Dumais asked 12 participants to return, three to six months later, to websites they had expected to revisit. Of the successful first attempts, 76% used methods that required no keeping at all: typing the address, using a search engine, or following a link from another site (Bruce, Jones & Dumais 2004). For stable pages such as official docs and Wikipedia articles, if you can find it again, keep only a link to the original; there's no need to save a copy.

But pages disappear. In 2024 the Pew Research Center checked a sample of about 90,000 pages from each year from 2013 to 2023: of the 2013 sample, 38% could no longer be reached a decade later, and that is by the most conservative measure (Pew Research Center 2024).

Read-later services disappear too. Omnivore announced the end of its cloud service in late October 2024; the export deadline was extended once, leaving users about a month to export; Pocket announced its shutdown in May 2025 and turned off exports that November. For personal blogs, social media posts, event pages and paywalled articles, if you can't find it again, save a summary or a copy rather than just a link.

Step 3: Can I write one sentence of my own about it? This is the remedy the collector's-fallacy essay prescribes: something enters the knowledge base only once you have read it and written down your own understanding. The sentence can be a view ("their test parallelization approach would work for our e2e suite") or a use ("when a deploy fails, run this first to see the logs"). For things that go out of date, such as API usage, prices or policies, put a date or version in the sentence. A small 25-person study found that the more of the key points people's notes captured, the more they remembered, while how many notes they took made no difference (Kalnikaite & Whittaker 2007). It didn't test writing in your own words, but it does show that more notes aren't necessarily better, so my suggestion is one more sentence per item rather than more items. If you can write the sentence, it goes into the knowledge base. If you can't, you haven't read it yet, so it goes on the to-read list. Step 2 has already kept a link or a copy of the original, so deleting a to-read item after two weeks is a decision that it isn't worth reading, not an accident.

Example: six items from one week, judged one by one

Saved this weekStep 1: useStep 2: findable again?Step 3: the sentenceWhere it goes
A payment provider's official webhook docsIntegrating payments this weekYes, official docs: link only"Signature verification needs the v2 header, 2026-10"Knowledge base (one line plus the link in the "payments integration" note)
A colleague's blog post, "How we cut CI from 40 minutes to 8"Our CI is too slow tooPersonal blog, may disappear: save a summary"Their test parallelization would work for our e2e suite, 2026-10"Knowledge base
A social media post with a git tipUseful every time I branchHard to find again: save the command"Use git worktree to work on two branches at once, no stash needed"Knowledge base
A 90-minute conference talkRelevant to the team's plans for next yearYes, on the video platform: linkCan't yet, haven't watched itTo-read list; delete if unwatched in two weeks
"Top 10 AI Tools of 2026"Can't name one——Delete
A long read on the history of Roman aqueductsPure curiosity——Read it and let it go

Of the six, three go into the knowledge base, each with a sentence of your own, one of them with only a link to the original; one goes on the to-read list, and two aren't kept.

Search and AI are so good now. Why filter at all?

"Full-text search and AI chat can find anything, so saving extra does no harm." Finding something and having read it are different, and the collector's fallacy is about the second. And once you let AI read your notes, the noise you collected gets used to answer you. Among the failure points Barnett and colleagues at Deakin University found in RAG systems is one where the answer is right there in the text the model received, but too much noise or contradictory information keeps it from being extracted. Stale old notes and conflicting versions may well be that kind of noise. The AI part of the series comes back to this.

"Does an AI-written summary count as my sentence?" No. The sentence exists to make you understand the thing, and an AI summary skips exactly that step. One study points the same way, though it wasn't about notes. In 2025 Melumad and Yun ran seven experiments with more than 10,000 people, asking participants to learn about a topic and then write advice for a friend. People who learned with ChatGPT reported learning less deeply than people who searched Google themselves, and wrote shorter, more similar advice, and the difference held even when both groups were given exactly the same information in a different form. What AI can and can't do for your notes is the subject of order 5.

How to do it in your tools

ToolWhere the inbox isWhere the to-read list isWhere the sentence goesDiscarding
Readwise ReaderThe default Triage layout is Inbox → Later → Archive; new saves land in InboxLaterHighlights can sync to Obsidian or Notion, and you write the sentence there; the sync only appends, so editing on one side doesn't update the otherDelete
Obsidian Web ClipperSet an inbox folder in the template, and every clip lands thereA separate "to read" folderAt the top of the note; you can add a "use" field to the note's propertiesDelete the note. Clipped images are saved only as links to the original URL by default, so download them if you need them long term
Notion Web ClipperClip into an "Inbox" database, which adds a URL property automaticallyA "status" property in the same database, filtered to "to read"Add "use" and "sentence" properties to the database after clipping; you can't add tags while clippingDelete the page

Whatever the tool, highlights and screenshots go through the same three steps: highlighting a lot is not the same as writing the sentence. Tools can disappear too, so export your knowledge base once a quarter into a format you can open yourself.

Limits of the research

Most of the research cited here is about email, bookmarks and paper files, often with a dozen to a few dozen participants. It addresses whether kept items can be found again; nobody has directly tested keep-or-skip criteria inside Notion or Obsidian. The three-step test is a practice distilled from this research, not an experimentally validated procedure. And if sorting your files causes you real distress and you can't bring yourself to delete anything, that may be digital hoarding, a condition researchers have not yet agreed how to define (Bravo-Adasme et al. 2026), and a new note-taking method won't fix it.

What you can do tonight

  1. Keep one inbox and start a separate to-read list. Bookmarks, read-later, messages to yourself: pick one as the only way in.
  2. Count your saves once. How many did you save in the past month, and how many did you use? That tells you whether step 1 should be strict or loose.
  3. Put 20 minutes a week in your calendar. Empty the inbox with the three steps: each item goes into the knowledge base, gets kept as a link, goes on the to-read list, or gets deleted.
  4. Export once a quarter, whatever tool you use.

Self-check

Q: You ask an AI to summarize a 30-page paper into five points, and they look useful. Do those five points go straight into your knowledge base?

How to judge: Take the three steps. Step 1: can you name a use? If not, don't keep it, however good the summary is. Step 2: can you find the paper again? Usually yes, so keep only a link to the original. Step 3 is the one that matters: those five points are the AI's words, not yours. Read the summary (and the relevant parts of the paper if you need to), and write one sentence of your own, such as "this method could solve our X, but the sample was only students". Then it goes into the knowledge base. If you can't, it goes on the to-read list.

References