Stop Building the Perfect Folder Structure

Somewhere in your organization there is a folder path eleven levels deep. It ends in a folder called something like "Final" which contains a folder called "Final Updated." Above it sit ten levels of category that somebody designed carefully, in a meeting, with a whiteboard, and which describe a version of the organization that stopped existing during a reorganization four years ago.

The taxonomy is not being ignored out of laziness. It is being ignored because the person filing a document has to answer a question the taxonomy cannot answer: does this belong under the department that produced it, the service line it applies to, the regulatory domain it touches, or the workflow it is part of? It is all four. The folder tree makes them pick one.

They pick the one nearest the top of the alphabet, or they make a new folder, and the tree grows a branch that nobody else will ever guess at.

Why hierarchies fail on real content

The failure is not a matter of designing the hierarchy badly. It is a property of hierarchies.

A tree requires that every item have exactly one parent. Operational healthcare content is multiply classified by nature. A tip sheet about downtime documentation for the emergency department belongs to emergency services, to informatics, to business continuity, and to whatever committee approved it. Any tree you build forces three of those four relationships to be represented by something other than location — a shortcut, a duplicate, a link that breaks on the next migration, or nothing.

The second failure is that the person filing and the person searching are different people with different mental models. The author files by origin: my department made this. The reader searches by need: I have this problem. Those are orthogonal, and no amount of care in designing the tree reconciles them, because the tree can only encode one of them.

The third is maintenance. A taxonomy encodes the organizational structure at the moment it was drawn. Organizations reorganize. Nobody re-files eleven thousand documents after a service line merges, so the tree becomes a historical record of a previous org chart, which is a genuinely interesting artifact and a poor navigation aid.

I have watched organizations respond to all three by concluding the taxonomy needs to be better and commissioning a project to redesign it. That project takes nine months and produces a tree with the same properties.

The position I would take

Stop building it. Or rather — stop building it for the purpose of helping people find things, because that is the purpose it is worst at.

Once retrieval works on meaning rather than on location, the navigational value of the hierarchy collapses. Nobody browses to a document they can ask for. Watch how people use a system that has both: the tree becomes a thing administrators look at and users never touch, exactly as happened to every intranet site map ever built.

That is a strong claim and I want to be honest that it is a claim about most content, not all.

Where structure genuinely earns its keep

Three things a flat corpus cannot do, and all three are worth building for.

Access control needs structure. Somebody has to be able to say that this class of document is visible to this set of roles, and doing that per-document does not scale past a few hundred items. That is a real, load-bearing use of categorization, and it should be designed for access rather than for browsing — which usually produces a much flatter and simpler structure than a navigational tree, because the number of distinct access patterns in a hospital is far smaller than the number of subjects.

Ownership and review need structure. Review cycles are assigned by category because assigning them individually is impossible. Retirement is scheduled the same way. This is the structure that actually keeps a corpus alive, and it is the one most often neglected in favour of the navigational one.

Authority needs structure. When two documents disagree, something has to decide which wins, and that decision is almost always made by class — approved policy beats departmental guidance beats a ticket resolution. Encoding that precedence is essential to retrieval working at all, and it is metadata, not a folder path.

Notice that all three are properties attached to a document, not places a document sits. That is the reframe I would push: you need classification, and you do not need a location hierarchy. Those got conflated because file systems made location the only available place to put classification, and we have been living with that constraint long after it stopped being a constraint.

What to build instead

A short, mandatory set of fields on every document, and the discipline to actually require them.

An owner, who is a named person and not a department. A last-verified date, which is different from a last-modified date and considerably more useful, because it distinguishes "someone fixed a typo" from "someone confirmed this is still true." An audience, in the vocabulary of the audience. An authority level, so precedence can be resolved without a meeting. And a title written as the question a person would ask, not as the subject a filer would file under.

That last one does more work than anything else on the list and costs nothing. "Armband printer will not print" is findable by the person with the problem. "Peripheral Device Troubleshooting Procedures" is findable by the person who wrote it.

Solution Compass leans on exactly these fields — ownership and verification dates to decide what to trust, authority level to break ties between documents that disagree — and it is the part of an implementation that is genuinely the organization's work rather than the vendor's. No retrieval system can infer that a document is authoritative. Somebody has to say so.

The migration is the moment

If you are going to do this, the window is a platform migration, and it is the only window you will get.

Migration is the one time an organization will tolerate a conversation about not bringing everything. Outside of a migration, proposing to delete documents is a fight with every department that authored one. During a migration, "what is in scope for the new system" is a question people expect to be asked.

Use it. Set inclusion criteria before the vendor's migration tooling gets involved, because once lift-and-shift is technically available it becomes the default by inertia — and the default quietly recreates the eleven-level tree inside the new platform, along with the folder called Final Updated.

Somebody built that tree carefully. It was a reasonable thing to build with the tools that existed. It is not a reason to build another one.