Your Notes Have a Second Reader Now

The Two Readers Want Different Things

They are not in conflict as often as you would expect, but where they differ, the difference is sharp.

Future you wants speed of capture and recognizability. A fragment is enough, because the fragment is a handle on a memory you still hold. Abbreviations are efficient. Emotional shorthand works: you will know exactly what "this is the thing" meant. Notes written for this reader optimize correctly for the friction of writing them, because the cost of capture is the thing that determines whether you capture at all, and a system nobody writes into is worthless regardless of how readable it would have been.

The model wants each note to stand on its own. It has no memory of the week you wrote it and no access to the surrounding conversation. What it has is the text in front of it, plus whatever other notes the retrieval step happened to pull, which may or may not include the one that defines your abbreviation. When a note depends on context that lives outside it, the model does not report that the context is missing. It fills the gap with something plausible, which is the failure mode that makes this worth caring about: not an error you can see, but an answer you cannot distinguish from a correct one.

Implicit Context Is the Main Failure

If you fix one thing, fix this. The single largest source of wrong answers from a model reading personal notes is context that the writer knew and did not write down, because at the time it was ambiguous to nobody.

It shows up in predictable forms. Pronouns without antecedents, where "he disagreed" is perfectly clear in the moment and unattributable a year later. Bare deictic references: "this approach," "the new plan," "that meeting." Project abbreviations and internal codenames that appear in forty notes and are defined in none. Decisions recorded without their reasoning, so the note says what was chosen but not what it was chosen over, which is the part you will actually want. And status words with no date attached, where "currently blocked" is true of some moment you can no longer identify.

The fix is not to write essays. It is to spend one extra clause naming the thing the first time it appears in a note. "He pushed back" becomes "Dana pushed back." "The Tuesday call" becomes "the Tuesday vendor call about pricing tiers." "Currently blocked" becomes "blocked as of 12 September, waiting on legal." These cost a few seconds each and they are the difference between a note that answers a question and a note that invites a confident fabrication.

Titles Do More Work Than You Think

For a human browsing a list, a title is a label. For retrieval, a title is one of the strongest relevance signals available, because it is short, it is weighted heavily, and it is often the only part of a long note that gets compared against the query in the first pass. A note titled "Notes" or "Meeting 9/12" is close to invisible to the thing trying to find it, and the file is not badly written, it is badly addressed.

A title that works for both readers states the claim or the subject in plain words. "Meeting 9/12" becomes "Vendor pricing call: we chose annual billing over monthly." "Article" becomes "Why context rot makes long prompts unreliable." The second version is longer and you will not regret it, because it is also the version that tells you what the note says when you scan a list of forty of them six months from now. This is one of the places where the two readers want exactly the same thing, which is why it is worth doing first.

The related habit is to state the conclusion inside the note rather than leaving it implied by the evidence. A note that lists five considerations and stops requires the reader to do the synthesis. Future you can, usually. A model will synthesize something, and it will not necessarily be what you concluded. One sentence at the top saying what you decided and why turns an ambiguous note into an unambiguous one, for both readers.

One Idea Per Note, For a New Reason

Atomicity is old advice, and the traditional justification is about linking: an idea that lives in its own note can be connected to other ideas precisely, which is the engine of a Zettelkasten. That argument still holds. There is now a second, more mechanical reason, and it is about how retrieval behaves.

A note covering six unrelated topics is a poor match for any specific query. It is somewhat relevant to all six and strongly relevant to none, so it tends to lose to notes that are about exactly one thing, and when it is retrieved it brings five topics of noise into the model's context. Multiply that across a library and you get the distractor problem: a prompt full of material that resembles the answer without containing it, which is one of the documented causes of degraded accuracy in long contexts. Splitting a sprawling note into three focused ones makes each one findable and makes the retrieved set cleaner.

The caveat is the same one that has always applied, and it is worth stating so this does not become a rule you obey past the point of usefulness. Atomicity is a property of ideas, not a word count, and forcing a genuinely multi-part argument into fragments destroys the argument. A long note about one coherent thing is fine, and often better than five stubs. The target is one subject per note, not one paragraph per note.

The linking argument and the retrieval argument arrive at the same practice from different directions. Atomic notes, explained →

Structure a Model Can Use

Beyond the prose itself, a few structural habits raise the hit rate noticeably, and none of them require adopting a system.

• Date things, in the note. Not only in the file metadata, which gets lost the moment a note is copied, exported, or passed into a prompt as raw text. A date inside the text survives every one of those.
• Spell out the entity at least once per note. Full names for people, full names for projects, and the expansion of any acronym the first time it appears. Assume the note will be read entirely alone, because it often will be.
• Put the conclusion first. A summary sentence at the top helps retrieval match the note, helps the model weight it correctly, and helps you skim. There is no reader for whom burying the point is better.
• Prefer real headings to visual formatting. A heading is structure a model can parse; bold text used as a pseudo-heading is a styling hint it mostly ignores.
• Keep quotes attributed and separated from your own thinking. The most damaging retrieval error is a model presenting something you disagreed with as something you believed, and undifferentiated transcription is how that happens.
• Write links with meaningful anchor text. "See the vendor pricing decision" carries information that "see this" does not, for both readers.

None of this is a new methodology and it should not become one. It is the set of habits that were always good practice, with the stakes slightly raised, because a second reader now depends on them and that reader does not tell you when it is confused.

What Not to Do

The obvious overcorrection is to turn note-taking into documentation: rigid templates, mandatory fields, a schema to satisfy before you are allowed to write something down. This reliably kills the habit. Capture friction is the thing that determines whether notes exist at all, and a perfectly structured empty library loses to a messy full one every time. If a convention here makes you less likely to write the note, drop the convention.

The subtler mistake is writing for the machine at the expense of the human. Keyword-stuffed titles, tag taxonomies maintained for a retrieval system's benefit, notes padded with context nobody needed. The two readers overlap far more than they diverge, and where they overlap, the human wins the tie. A note that is clearer to you is almost always a note that retrieves better, because the qualities that make it clear, a real title, a stated conclusion, named entities, one subject, are exactly the qualities retrieval uses.

And the most practical point: much of this can be done for you after the fact. Tagging, summarizing, extracting dates and names, connecting a note to related material, these are mechanical tasks and they are precisely what automatic organization is good at. The part that cannot be automated is the context that only you had at the time of writing. Spend your effort there and let something else handle the filing.

Mindly does the mechanical half on arrival, so the only thing left to you is writing down what you actually meant. How the organizing works →