Tagging is a tax you pay before you know what matters.

Every system for organising notes asks you to do some work. The interesting difference between them is not how much work, it is when they ask for it. Some want it before you write anything, some want a little on every entry forever, and some want it once, after the writing already exists. That timing decides whether you are still using the system in a year more reliably than any feature does.

A tag is a prediction.

When you write #checkout on a note in January, you are betting on three things at once. That checkout will still be a category you care about in December. That you will spell it the same way every time, and not drift into #checkout-flow in March and #payments in July. And that the version of you who goes looking in December will think to search for that word rather than one of the others.

Those are three separate bets and they are placed at the worst possible moment, which is before you know what the year contains. A tag vocabulary is a schema you are designing while distracted, one entry at a time, with no way to see the whole thing.

The single-use tags are the tell. They are not organising anything, and they make the autocomplete list long enough that you stop reading it and start inventing new tags, which produces more single-use tags. The vocabulary decays on its own unless somebody spends an afternoon a quarter pruning it, and almost nobody does.

Three ways to get structure.

The tax is charged at the worst moment.

Look at when the middle row bills you. Tagging asks for its payment on every entry, which means it asks during the incident, at the end of the long day, and in the ten seconds before a meeting. Those are exactly the entries you will want back, and they are exactly the entries that get tagged badly or not at all.

The result is a log with a coverage hole shaped like your worst weeks. The calm Tuesdays are beautifully tagged. The Thursday everything broke has one line and no tags on it, and that Thursday is the one somebody asks about in the postmortem.

Deriving structure afterwards.

The alternative is to write plainly and pull the structure out later. A ticket reference looks like a ticket reference. A hostname looks like a hostname. A measurement is a number next to a unit. These are patterns, they were already sitting in the prose, and a pattern can be applied to six years of notes in one pass rather than one entry at a time.

What changes is when you commit. You describe the shape of a ticket reference once, after you have seen a few hundred of them and know what they look like, rather than guessing in month one. If you get it wrong, you adjust the pattern and everything you have ever written is reprocessed. Nothing has to be revisited by hand, because you never wrote the structure down in the first place; you wrote sentences.

This also works on notes that predate the decision entirely. The years of files you kept before you had any system are not a lost cause, they are just unprocessed input. That is the property none of the other two approaches has, and it is usually the one that decides the question, because most people considering this have a folder of old notes rather than a blank slate.

What deriving costs you.

It cannot see what is not there. An entry that says "the usual problem came back" contains no ticket, no host, and no number, and nothing recovers those afterwards. The habit that makes this approach work is naming things in ordinary sentences, which is covered in more detail in the first article below, and it is a real habit rather than a free lunch.

Patterns also produce false matches. A version string can look like a ticket reference. A heading can look like a tag. You end up adjusting the patterns a few times in the first week, and the adjustment is cheap only because reprocessing is cheap. If you find that tuning irritating, the honest comparison is that tagging asks for a smaller irritation far more often.

And it gives you less than a hand-curated system at the very top end. Somebody who genuinely maintains a clean, small, stable tag vocabulary will retrieve better than anything derived. That person exists. They are rarer than the number of tools sold to them would suggest.

Tagging is not wrong.

None of this makes tags a mistake. They are the right tool for a vocabulary that is small, stable, and genuinely chosen rather than accumulated: a handful of project names, a priority, a status. The mistake is expecting an open-ended tag vocabulary to do the job of a derived index, and then blaming yourself for the drift when it does what open-ended vocabularies do.

A workable split is to let dates and names carry the retrieval, and reserve tags for the few categories you would defend in a conversation. That keeps the vocabulary short enough to stay accurate, and it puts the structural work somewhere it can be redone rather than somewhere it has to be maintained.