When I first started using Obsidian, I thought more links meant a better note system. To be fair, the graph view looks ridiculously cool the moment you turn it on. Whenever I saw a related term, I made it a [[link]]. A denser graph looked more convincing too.

Later, I followed those links and often could not remember why I had connected them. Some notes were linked only because they covered the same topic. The list of links was long, yet it had become even less clear where to start reading.

Now I assign different questions to wikilinks and MOCs.

  • A wikilink answers, “What is this connected to, and in what way?”
  • A MOC answers, “In what order, and from what perspective, should I read?”

Both connect notes. A link creates a relationship; a MOC creates a path.

Another post on this blog Properties and Tags: Two Layers of Note InformationThe rules I use in Obsidian to keep Properties as minimal machine-readable structure and tags as cross-cutting topics. #pkm

A wikilink is not a tag that mechanically groups notes on the same topic. It lets me refer to one subject from several contexts without copying its contents, while the surrounding sentence explains how two ideas relate.

Keeping sessions off the server makes [[statelessness-in-system-design|horizontal scaling]] easier.

This link does not merely say that both notes are about system design. The sentence explains that statelessness enables horizontal scaling. Instead of twisting a sentence to match the title of the linked note, I would rather show the role that note plays in this context.

For people, organizations, products, technologies, and events that I expect to reference repeatedly, I create a named note and link to it. With aliases, different names can still lead to the same subject, and unlinked mentions become easier to find.

But I do not turn every noun into a note. Nor do I connect every note simply because it shares a topic. I link only relationships that I expect to use again as evidence, contrast, or premise. A note under sources/ can have no links at all when the preserved source has no meaningful relationship to express.

The rule I settled on in the spatial-axis post is that “notes do not migrate.” When a note takes on a new role that belongs in another folder, I do not move the existing file.

  • When a source gives me an interpretation of my own, I write a new note under notes/ and link the source as evidence.
  • When I find a reusable principle in a log, I create a new note under notes/ and link the record from that moment.
  • When reviewing an inbox capture produces a canonical note, I check the relationship between them, then keep or delete the capture.

This keeps external material, records from the time, and my current interpretation from overwriting one another. Each canonical note stays in its own place, while links preserve the movement of thought. I describe this division in more detail in the post about sources, logs, and wikilinks.

External evidence and historical records connect meaningfully to a current interpretation, while a MOC arranges core concepts, counterexamples, and applied records into a reading order

Tags and search show what exists. They do not tell me what to read first, where to examine a counterexample, or which practical case should come next. That is when I create a MOC (Map of Content) under atlas/.

Every link in a MOC gets one line explaining why it belongs on that path.

- [[Core concept]] — Establish the premise for this path.
- [[Counterexample]] — Find the conditions under which the premise breaks.
- [[Application record]] — See how it worked in a real situation.

A list of links with no reasons is not very different from a search result. A MOC is not an index; it is a map. It chooses a starting point, shows where I am, and reveals where perspectives diverge.

One note can appear in several MOCs. The file is not being copied; the reading purpose is different. The same note might be connected as a decision criterion in an investing MOC and as an automation example in an AI MOC. Each MOC only needs to explain why the note should be read there. MOCs can also connect to parent or peer paths.

Frozen does not mean worthless

A MOC also has a right endpoint on the time axis. But I do not automatically add state: archived when a project ends.

  • If it is a reading path I will continue to revise, I leave out state.
  • If I will no longer revise it but it remains useful for exploration or retrospection in an area of interest, I freeze it with state: archived.
  • If it no longer has exploratory value, I clean up its references first and delete it.
  • If the fact that an idea or piece of information was wrong is itself useful, I reduce it to a short correction note explaining why.

archived does not mean an abandoned map. It is a path that remains within my area of interest but is no longer being revised. Project completion, freezing, and deletion are not the same event.

Before deleting a note, I first repair the places that refer to it. If it contains original evidence, I replace the link with the source URL. If another canonical note has taken its place, I point there instead. Deletion is less about removing one file from the graph and more about cleaning up the relationships that file used to carry.

I used to think that a note was well connected when it had many links. Now I first ask whether I can understand the relationship when I follow one.

I use a tag to collect the same cross-cutting topic. I use a wikilink to preserve a relationship between a thought and a specific subject. I make a MOC when several relationships need a perspective and an order for reading.

Connection is ultimately about reasons, not quantity. If a link inside a sentence explains the relationship and one line in a MOC explains the reading purpose, even a sparse graph can be reused. The note system I want is not the one with the most connections. It is the one in which I can remember why they were made.