Document by Type, Not by Context

A knowledge base I run grew past sixty documents and turned into chaos. Two folders both effectively held "financial models." One document had been copied into three places because it got used in three meetings. The mess was not volume. It was the wrong organizing axis.

Sixty documents is not a lot. I have built and dissolved knowledge bases ten times that size without breaking a sweat. So when this one started to rot, I knew the problem was not scale. It was the question I had asked when I created each folder.

I had been asking: where was this used? The investor meeting. The board prep. The partner sync. Each occasion got a folder, and into each folder went whatever showed up that day. It felt natural. It maps to how the week actually unfolds. It is also how you guarantee duplication and version drift, because the same document belongs to many occasions, and an occasion-based structure has no way to say "there is only one of these."

Context is a copy machine

Here is the failure in slow motion. A financial model gets built for an investor meeting, so it lands in the investor folder. Two weeks later the same model gets pulled into board prep, so a copy lands in the board folder. Someone tweaks the board copy. Now there are two models, both live, both slightly wrong, and no marker anywhere telling you which one is real.

Multiply that by every document that ever crossed more than one meeting. That is what sixty documents looked like. Not sixty things. Maybe forty things, wearing twenty disguises, drifting apart from their originals one small edit at a time.

The deeper issue is that context is not a property of the document. It is a property of an event. A model does not become a different object because you opened it in a different room. But a context-based folder structure insists that it does, and it punishes you with a copy every time you cross a boundary.

Type is a single source of truth

The fix was to organize by what each document is, never by where it got used. One folder per type. All financial models in one place. All investor materials in one place. All legal documents in one place. The occasion that pulled a document into a meeting becomes a fact about that meeting, not a location on disk.

This forces the thing context can never give you: one canonical copy per document. When every model lives in the same folder, you cannot quietly fork one into another room, because there is no other room. If genuine variants need to coexist, they live together, side by side, with an explicit marker naming which one is canonical. An archive subfolder holds the history so nothing is lost, but nothing stale pretends to be current either.

The rule I now run on the knowledge layer of my spine is one line. A document lives in exactly one place, chosen by what it is. Where it was used is metadata, not a folder.

The second-order payoff

The part I did not expect was what type-based structure did to my discipline.

When you place the same type of document over and over into the same folder, consistency stops being a thing you remember to do and becomes a thing the structure does for you. I open the financial models folder and I see eleven files that all follow the same date-first naming. The next model I drop in wants to match them. The folder itself is teaching me the convention. Date-first filenames, clear ownership, a visible canonical marker - none of it requires a checklist anymore, because the neighbors enforce the standard.

Compare that to context folders, where each occasion holds a random assortment of types and no convention can take hold. You cannot build a habit on top of variety. You can only build one on top of repetition, and type-based structure is repetition by design.

The team payoff is the one I care about most. We are a small team running a venture together. A teammate or a partner never has to ask which version is live, because there is only ever one, and it sits where its type says it should. Nobody rebuilds a model from scratch because they could not find last quarter's, because last quarter's is in the archive subfolder one click away, clearly marked as old.

That is what coherence looks like for a small team. Not a heroic act of communication. Not a weekly sync where someone reads out the current state of every file. Just a structure where the right answer is the only answer the filesystem will let you give.

So when you build the knowledge layer of your own system, ask one question of every folder you create: does this name describe what the documents are, or where they happened to be used? If it is the second, you have built a copy machine. Rename it after the type, move the duplicates into one place, mark the canonical one, archive the rest. Then watch how much of the coordination you used to do by hand the structure starts doing for you.

Field Notes from the Agentic Operator is a personal series. These are my own views, not those of my employer or any organization I work with, and nothing here relies on non-public information.