Where Should a Note Live?

Anyone who keeps notes eventually runs into this question.

“Where should this note go?”

I changed my folders quite often because of it. I created a development folder, moved notes into project folders, and wondered whether a note belonged to productivity or PKM. Every new structure looked as if it might last. As the number of notes grew, the boundaries blurred again.

Looking back, I did not need more folders. I was asking folders to answer too many questions.

Dividing space by topic was the problem

A file cannot live in several folders at once. One note has one path.

Topics do not work that way. Imagine a note about Obsidian security settings. It can be about obsidian, while also overlapping with security and privacy. A topic-based folder system forces me to choose one of the three.

I could copy the file into several places, but that immediately creates another problem: which copy is canonical, and which one should I edit? If I keep only one file, I lose the paths into it from the topics I did not choose.

When notes keep resisting folders, the classification may not be too coarse. I may have assigned a question with several valid answers to a tool that permits only one.

A folder answers one question

So I redefined the spatial axis. Instead of topic, a folder now answers: How should I treat this note?

In my vault, a note’s place depends on where it came from and how I will handle it from now on.

This is not a perfect classification either. But “How should I treat it?” is easier to answer, and more stable over time, than “Is it security or privacy?” Topics keep multiplying and one note can belong to many of them. Where a note came from and how it should be handled leaves me with fewer choices.

A folder is the one place where a note physically lives. Tags, wikilinks, and MOCs let me see that file from other perspectives without copying it.

A topic is not a location

Reducing the number of folders is not enough. I have to assign the questions abandoned by folders to the right tools.

A tag answers, “Under what topic will I want to find this again?” Because a note can have several tags, they express multiple membership well. But tags become another classification hierarchy when there are too many, so I keep only cross-cutting topics that are genuinely useful to view together.

A wikilink answers, “What does this connect to, and in what way?” A named subject such as Node.js or Kubernetes belongs more naturally in a link than a tag. What matters is not the number of links, but explaining inside the sentence why they are connected.

I describe how I divide Properties and tags in the post about Properties and tags, and how I create meaningful relationships and reading paths in the post about wikilinks and MOCs. The more concrete rules for separating source material, records from the time, and my own thoughts are in the post about sources, logs, and wikilinks.

A MOC (Map of Content) answers, “In what order should I read?” It is not an index that repeats a search result, but a map that shows a starting point and where perspectives branch. Every link explains why it belongs on the path. The same note can appear in several MOCs while remaining one file.

Notes do not migrate

The hardest problem left after defining the spatial axis was inbox/. It seemed reasonable to review a capture, then move it into sources/, notes/, or log/. But when a file move carries meaning, the file itself appears to change roles.

I now use a simpler rule: notes do not migrate. When a different role requires a different folder, I create a new note in the place appropriate to that role.

• An unreviewed capture remains in inbox/, while an adopted idea becomes a new note under notes/.
• External material remains in sources/, while my interpretation of it becomes a new note under notes/.
• A record from a project remains in log/, while a principle I expect to reuse becomes a new note under notes/.

I connect the new and previous notes with a wikilink. If the old capture is valuable as evidence of change or provenance, I keep it. If it has no independent value, I delete it after checking its references. I do not move or duplicate a file simply because its topic changed. Adding or removing a topic is the job of tags and links, not a reason to move a file.

inbox/ needs the most care under this rule. Because it accepts things I have not judged, it easily turns into storage. I review captures within 30 days, create a new canonical note in the right place or discard them, and do not postpone the decision by keeping the inbox file forever.

Simpler folders left me with the work of writing

I used to think every ambiguous note called for a new folder. Now I change the question.

How should I treat this note? Under what topic do I want to find it? What does it connect to? In what order should I read it again?

When folders, tags, wikilinks, and MOCs each take one question, I need fewer structural overhauls. A new topic does not require a new folder, and a note that touches several interests does not need copies. The file has one place, while meaningful relationships can extend in several directions through sentences.

What I wanted was not a folder structure capable of perfectly describing every note. I wanted a structure that made me hesitate less while writing and left only one place to edit later.

The spatial axis does not explain the full meaning of a note. It only decides how the file should be treated. Perhaps that limited responsibility is exactly what makes folders durable.