Naming feels like the most trivial decision in note-taking, and it quietly determines whether you find anything. The title is the only part of a note you see in a search result, a file list, or a link. It is doing more work than the note's contents most of the time.
The rule that changes the most
Title the note with its claim, not its topic.
| Topic title | Claim title |
|---|---|
| Meeting notes | Pricing decision deferred to Q3 |
| Spaced repetition | Spacing beats massing even when total study time is equal |
| Onboarding thoughts | Onboarding fails at step 3, not at signup |
| Article: attention | Attention residue explains why short meetings still cost an hour |
The topic titles tell you where a note lives. The claim titles tell you what it says, which means you can decide whether you need it without opening it, and you can see the argument by reading the list.
Andy Matuschak's framing is that evergreen note titles work like APIs: the title is the interface other notes call, so it should be precise enough that you can use the note without reading its body. That is a high bar and worth aiming at, because a title you can link to as a phrase in a sentence is a title that has captured an idea rather than a subject.
It also enforces a useful discipline. If you cannot write a claim title, the note is probably about more than one thing. That is the atomic notes principle arriving through the back door, and splitting the note is usually the right response.
When topic titles are correct
Not everything is a claim. Some notes are containers, and containers should be named as such.
- Index and hub notes. "Machine learning" is the right name for a map of content. It is a place, not an argument.
- Reference material. "Postgres connection string formats." Nobody wants a claim here, they want the lookup.
- Recurring logs. "2026-07-28 standup." The date is the identity.
- Projects. "Website redesign." A workspace, not an idea.
The test: is this note something you think with, or something you look up? Claims for the first, topics for the second.
Dates, and where they belong
Dates in titles are useful in exactly one case: when the note's identity is the moment it was made. Daily notes, meeting notes, journal entries, and interview records all qualify.
Use ISO format, 2026-07-28, leading. It sorts correctly everywhere, it is unambiguous across countries, and it does not break when the year rolls over. 28/07/26 fails all three.
For everything else, leave the date out. A note titled "2026-03-14 thoughts on pricing" is findable only if you remember March, and you will not. The file already knows when it was created.
The hybrid that works for meetings: 2026-07-28 Acme kickoff — scope cut to phase 1. Date for sorting, participants for searching, outcome for reading the list.
Rules worth adopting
Write titles a search would produce. Use the words you would type when looking for it, including the ones you would use in six months. If you would search "why the deploy broke," do not title it "post-incident retrospective."
Front-load the distinctive word. Lists truncate. "Pricing: why we deferred the increase" survives truncation. "Notes and thoughts on the question of pricing" does not.
Avoid your own jargon in titles. Abbreviations you invent today are unreadable in a year. Inside the note, fine. In the title, spell it out.
Never number notes for ordering. 01-intro, 02-setup is a structure encoded in a filename, and it breaks the moment you need something between 01 and 02. If order matters, put the order in an index note. The exception is a deliberate ID scheme like Johnny.Decimal, where the number is an address, not a sequence.
Be careful with characters. / : * ? " < > | break filenames on some systems, and #, [, ] have meaning in Markdown and in most linked-note apps. Colons in particular fail on Windows and in YAML frontmatter. Use a comma or a dash.
Keep them under about ten words. Long enough to state a claim, short enough to read in a link.
Renaming, and why it is a feature
Titles should change. A note starts as "thoughts on caching" and becomes "cache invalidation is a naming problem" once you understand what you were circling.
That rewrite is not tidying, it is the moment the thinking finished. Notes that never get renamed are usually notes that were never developed, and a system where renaming is painful will quietly discourage you from developing them.
Two practical consequences. Check whether your app updates links when a note is renamed. Obsidian, Logseq, and most modern tools do. Plain files and folders do not, and a rename there means fixing every link by hand, which is enough friction to stop you.
And if you are using an ID-based scheme, the ID is what links point at, so renaming the human-readable part costs nothing. That is the actual argument for numeric IDs in a Zettelkasten, and it is more compelling than the tradition.
Naming and finding are the same problem
All of this is downstream of one question: how will you get back to this note?
If your answer is browsing a folder tree, titles carry the whole load and need to be scannable. If your answer is search, titles need to contain the words you would search for. If your answer is following links from an index, the title needs to read well inside a sentence.
Most people use all three, which is why claim titles win: they scan, they contain real keywords, and they read as prose in a link. See tags vs folders for the retrieval architecture around them, and how to organize your notes for the wider system.
Worth saying plainly: naming is a tax you pay because tools cannot yet read what a note means. Search that understands the idea rather than the string removes some of it, which is the direction Clair Mind works in. Until then, a good title remains the cheapest retrieval insurance available.
More in personal knowledge management and PKM mistakes.