The failed solutions

The problem is not new. People have been trying to solve it for decades. Each attempt solves part of the problem and creates new ones. Understanding why they fail is not an exercise in criticism; it is the foundation for understanding what a real solution requires.

The file system: a tree in a world of webs

The oldest solution is the simplest: organize everything into folders.

The file system is a hierarchy. Folders inside folders, branching from a single root. Every file has exactly one location, one path. It is a tree, and trees are elegant, until your information is not tree-shaped.

Where do you put a document that belongs to a project and to a client and to a topic you are researching? You pick one folder and hope you remember. Or you make copies, and now the same document exists in three places, and when you update one, the others go stale. Or you make shortcuts, which are the file system's way of admitting that its model is insufficient.

The deeper problem is that the file system captures nothing about what a file is or how it relates to other files. A folder called “Projects” tells you nothing that the word “Projects” does not already say. The file system has no concept of relationships, no concept of types, no concept of meaning. It is a storage system that asks you to do all the organizing in your head.

This worked when people had dozens of files. It does not work when they have thousands, spread across multiple devices, synced through multiple services, in formats that range from plain text to proprietary binaries.

The SaaS era: renting your own life

The next wave of solutions came from the cloud. Instead of organizing files yourself, let a service do it. Gmail organizes your email. Google Drive organizes your documents. Trello organizes your projects. Spotify organizes your music. Each one handles its domain well.

The trade-off is sovereignty. Your email is not a file on your machine; it is a row in Google's database. Your notes are not documents you own; they are entries in Notion's infrastructure. You access them through someone else's interface, subject to someone else's decisions about features, pricing, and continuity.

This is not hypothetical. Google has shut down products with active users (Google Reader, Inbox, Google+, Stadia). Evernote changed pricing and lost millions of users who discovered that exporting a decade of notes into a usable format was somewhere between difficult and impossible. Slack's free tier now deletes message history after 90 days. The pattern is consistent: you build your workflow around a service, and the service changes the terms.

But sovereignty is only half the problem. The other half is fragmentation by design. Each SaaS product is an island (and not the useful kind). Your email knows nothing about your project tracker. Your project tracker knows nothing about your notes. Your notes know nothing about your calendar. Each service optimizes for its own domain and has no incentive to connect with the others. Your information is not just scattered across your own folders; it is scattered across other people's servers, behind other people's APIs, in other people's formats.

Some services try to be the hub that connects everything. Notion, Coda, Monday.com: each one promises to be the single workspace where everything converges. This is the canal: a centralized channel that forces all the water through one point.

It works, for a while. Then the canal overflows. The center accumulates too much, the periphery still cannot connect on its own, and you are back where you started, except now your dependency is on a single provider instead of many.

The “second brain”: better, but not enough

The personal knowledge management (PKM) movement recognized the problem more clearly than the SaaS industry. Tools like Obsidian, Logseq, Roam Research, and others proposed something genuinely different: local files, open formats, bidirectional links. Your notes live on your machine, in Markdown. You can link any note to any other note. The graph view shows you the connections.

This is a partial improvement. Local files solve the sovereignty problem: your data is on your machine, in formats you control. That matters. But bidirectional links do not solve the connection problem. They signal that a connection exists; they do not define it, name it, or differentiate it from any other connection. A link from note A to note B creates no more meaning than a hyperlink on the web.

The PKM community has produced serious thinking about how to organize information, but the tools themselves remain information systems.

A link between two notes says “these are connected.” It does not say how. It does not say why. It does not say what the connection means. You can look at a graph of 500 interconnected notes and learn almost nothing from it, because the graph shows topology (what connects to what) without semantics (what the connections mean).

The link between “Meeting notes: March 5” and “Project Understanding” could mean “this meeting was about that project,” or “this meeting decided to cancel that project,” or “someone in this meeting mentioned that project in passing.” The link carries no information about its nature. A human reading both notes can infer the relationship. A machine cannot. And, crucially, the human who made the link six months ago may no longer remember what it meant.

There is a second limitation. PKM tools are designed for one person working in one vault. The moment you need to collaborate, or to maintain separate spaces for separate contexts, or to have different levels of access for different people, the model breaks. You either put everything in one vault (and lose boundaries) or split into multiple vaults (and lose connections). There is no architecture for managing both at once.

And there is a third limitation, the one that is easiest to overlook: PKM tools inherit the oldest assumption in personal computing. The tool defines the structure. Obsidian gives you folders and tags. Logseq gives you an outliner. Roam gives you blocks and references. Each one is a significant improvement over file systems, but each one still tells you how to organize. The human adapts to the tool's model, not the other way around.

The pattern of failure

Every failed solution follows the same pattern:

1. Recognize a real problem. Fragmentation, access, organization, connection.
2. Solve it within the tool's own boundary. Gmail solves email search. Obsidian solves note linking. Notion solves structured data.
3. Ignore everything outside that boundary. The tool works for its domain and is blind to everything else.
4. Force the human to be the integrator. You are the one who knows that the email, the note, and the project are related. You carry the connections. You do the translation between systems.

The result is always the same: the human is the only knowledge layer. The tools manage information; the human manages meaning. And meaning does not scale. You can remember the connections between fifty things. You cannot remember the connections between five thousand.

That architecture is what the next section describes.

Previous: The problem | Next: The model