Capturing highlights, clippings, summaries, and notes does not establish that the right item can be retrieved later. Storage and task-specific retrieval are separate capabilities, and both need observable tests.
The focus here is the second skill: retrieval. Not “capture everything, organize later,” but a small, deliberately narrow system built around things you actually reuse, with a test for whether it works and a rule for what you should never have kept in the first place.
Volume of notes is not evidence of a working system. Define a retrieval-time target from the real task, then test whether authorised users can find the correct current item without exposing unrelated data.
This task-first approach is consistent with research on task-based evaluation of personal information management, which treats re-finding performance as dependent on a person’s collection and retrieval task. That research supports testing with real tasks; it does not validate this article’s example anchors, timing targets, or review cadence.
Hoarding versus retrieval
Hoarding feels productive: you save an article, highlight a passage, ask AI to summarize a meeting, and the growing pile feels like accumulated understanding. But a pile you cannot navigate is functionally the same as nothing — worse, in some ways, because it also costs you the time spent capturing it and the false confidence that “I saved this, so I know it.”
Retrieval is different: a small number of notes, tagged or structured well enough that when a specific, real situation comes up, you can find the relevant one fast and actually use it. The measure of a knowledge system is not how much it contains. It is how often the thing you actually needed was findable when you needed it.
Step 1: Anchor the system to three real things, not “everything”
Do not design a system for all your future knowledge needs. Pick three concrete, recurring anchors — either decisions you make repeatedly, or outputs you produce repeatedly — and build the system around only those.
Examples of a good anchor:
- “Which vendor to use for X” — a decision you revisit every year or two.
- “Client onboarding email” — an output you write some version of every few weeks.
- “How I explained this concept to a beginner” — a recurring teaching or writing task.
- “What worked in past performance reviews” — a decision-support need on a fixed calendar.
An anchor is a reasonable candidate if you can name concrete past instances when you needed it and explain the future task it supports. Frequency and look-back period should match that task: an annual compliance decision and a weekly client email are both recurring, but on different schedules. If you cannot identify a real past use, label the anchor experimental instead of assuming it deserves permanent capture.
Step 2: Decide what is worth capturing — and what is not
For each anchor, capture only material that would change what you do next time the anchor recurs. A useful filter question: “If I lost this note, would I make a worse decision or produce weaker work next time?” If the honest answer is no, do not keep it.
For what you do keep, capture four things alongside the content itself:
- Source — where it came from (a document, a conversation, a decision you made and its outcome).
- Date — when it was true; context ages.
- Why it mattered — the one-sentence reason this is worth having later, written at capture time, not reconstructed later from memory.
- Confidence or status — is this settled, still evolving, or a one-off exception that should not be generalized?
Skipping the “why it mattered” field is a plausible and testable cause of poor retrieval, not a measured universal ranking. Six months later, a highlighted paragraph with no context may be hard to interpret; test whether this field improves retrieval in your own system.
Step 3: Build a retrieval test, not just a filing system
A knowledge system needs a task-derived retrieval test. For each anchor, choose a target that fits the real decision or output. “Find and use the relevant note in under two minutes” is one illustrative target for a time-sensitive personal task, not a research-backed universal threshold.
Run the test honestly for something you already have notes on. If it misses your chosen target, or you cannot find anything relevant despite knowing you saved something, the result identifies something to investigate, such as:
- notes are not tagged or titled around the anchor’s actual future search terms;
- notes are scattered across too many tools (a notes app, email, chat history, a document, three browser bookmarks);
- the “why it mattered” field is missing, so a match does not confirm relevance without rereading everything.
AI-assisted search and summarization (a personal RAG tool, an AI-searchable notes app) can meaningfully speed up retrieval once material is captured with enough structure to search — see building a personal RAG and NotebookLM as a personal knowledge base for two concrete ways to do that. Neither tool fixes badly captured material; both are faster ways to search well-captured material.
Step 4: Set a review date, not an indefinite archive
Every anchor should have a review trigger or schedule based on how quickly its information changes and the harm of stale retrieval. Quarterly is an example, not a validated default. At review, check accuracy, merge or link duplicates where appropriate, and delete material no longer justified by the anchor and applicable retention rules.
Here are my notes tagged for the anchor "[name it]":
[paste notes]
1. Flag anything that looks outdated, contradicted by a later note, or
a one-off exception that should not be treated as a general rule.
2. Group near-duplicate notes and suggest which single version to keep.
3. For each note, ask me: would losing this change a future decision?
If I say no, mark it for deletion.
Do not summarize the notes into new claims I have not made. Only
organize and flag what is already there.
Step 5: Set a deletion rule before you need one
Decide in advance what should never be kept at all, rather than deciding case by case under time pressure. A short, working deletion rule:
- Delete anything whose only value was momentary — a passing fact, a link that will be stale in a month, a fleeting reaction.
- Delete or heavily redact anything containing another person’s private information you would not want them to find in your notes.
- Review material captured “just in case” that has never been retrieved; delete it only after checking purpose-specific legal, tax, warranty, dispute, safety, archival, and personal needs. Age alone is not a universal deletion rule.
For organisational personal data, do not copy the one-year example as policy. Define purpose-specific retention with your privacy owner. The European Commission’s GDPR principles overview covers purpose limitation, data minimisation, accuracy, storage limitation, safeguards, and accountability. Local household use and organisational processing can have different legal treatment; get qualified advice for the system you actually operate.
Sensitive notes need a different default
Some captured material is more sensitive than an ordinary reference note: health details, relationship or family matters, salary and financial information, disputes, or anything you would not want read aloud. Treat these differently from the start rather than relying on remembering to clean them up later.
A “personal” note, chat history, or AI memory feature may still be stored by a provider and subject to that provider’s contract, retention, security controls, authorized access, and legal process. “Personal account” is not proof that data is inaccessible to others. For genuinely sensitive material, use an approved boundary: for example, encryption you control, a verified local-only design, or a provider and plan whose current data-use, retention, deletion, access, and recovery terms have been reviewed. What ChatGPT remembers, sees, and shares covers the controls of one mainstream assistant; verify the current product and plan rather than generalizing it to every tool.
For notes about other people specifically — a colleague’s performance issue, a friend’s medical situation, a family conflict — apply an extra filter: would this person be comfortable knowing you kept a record of it, in this level of detail, in a tool outside your own head? If not, either do not capture it, or capture a much shorter, less identifying version. Their information is not yours to retain in detail just because the conversation happened to you.
A worked example
Anchor: “Which contractor to hire for home repairs.” Real recurring decision, revisited every year or two.
- Capture: after each job, one note — contractor name, job type, date, cost, what went well or badly, whether you would rehire, one line on why it mattered (“only one who returned calls promptly”).
- Retrieval test: next time you need a plumber, choose a task-appropriate target and test whether the last relevant note is returned accurately without exposing unrelated notes. A two-minute target is merely an example.
- Review date: once a year, before the season you typically need repairs, skim all contractor notes and delete entries for anyone who moved away or stopped operating.
- Retention rule: decide separately how long quotes, invoices, warranties, tax records, and dispute evidence must be kept. Do not copy a one-year rule from a knowledge-management example; retain only what has a documented purpose for the required period.
Nothing here is complex. That is the point — a system this small, kept for three real anchors, beats an ambitious “second brain” that captures everything and retrieves nothing.
Common failure modes
- Capturing everything “just in case.” Volume grows, retrieval rate does not; the system becomes a second inbox rather than a working memory.
- No “why it mattered” field. A highlighted paragraph or saved link with no stated reason is nearly as opaque in six months as never having saved it.
- Scattering one anchor across too many tools. If “vendor decisions” live partly in email, partly in a notes app, and partly in chat history, retrieval fails even when every individual note is well written.
- Treating a personal AI memory feature as a knowledge system. Model memory is built to make conversations feel continuous, not to be a searchable, reviewable archive with a deletion rule you control. Use it for convenience, not as your only record of something that matters.
- No deletion rule, so sensitive or stale material accumulates indefinitely because removing it was never anyone’s job.
What this system cannot do
Search and AI summarization can propose relevant material from what you stored. They cannot establish that a note is accurate, current, lawfully retained, or appropriate for the decision. A badly captured note — no context, no date, no reason it mattered — may remain unsafe or unhelpful even when a model can retrieve it. Keep ownership of capture and deletion rules with the authorized person or records owner.
Use the personal knowledge lifecycle map to pick your three anchors, define capture criteria, choose and run a task-appropriate retrieval test, and set your review trigger and retention/deletion rules before adding more material.
