The hierarchy you picked is not the hierarchy
You have a collection of notes, or books, or projects, or skills. You organized them into a hierarchy. It felt right at the time. Folders, categories, an outline — some structure that puts every item in a place. And then one day you needed to find something and the hierarchy failed you. Not because it was sloppy. Not because you miscategorized anything. It failed because you were asking a question that your hierarchy was never built to answer.
This is not a failure of execution. It is a property of hierarchies themselves.
The same set of items can be organized into multiple equally valid hierarchical structures. Each hierarchy privileges certain relationships and suppresses others. The hierarchy you chose is one view. There are others — just as accurate, just as internally consistent — that reveal what your current view conceals. Until you grasp this, you will keep blaming your organization skills when the real issue is that you have mistaken one possible arrangement for the only possible arrangement.
One dataset, many structures
Consider a university's course catalog. The same 500 courses can be organized by department (Computer Science, Philosophy, Biology), by level (introductory, intermediate, advanced), by requirement type (core, elective, capstone), by delivery format (in-person, online, hybrid), or by enrollment size (lecture, seminar, independent study). Every one of these hierarchies contains the same 500 courses. None contradicts the others. Each makes certain questions trivial to answer and others nearly impossible.
The department hierarchy answers "What courses does the CS department offer?" instantly. But it cannot easily answer "What 300-level courses are available as online seminars?" That question cuts across three dimensions — level, format, and size — that the department hierarchy does not expose.
This is not a flaw of the department hierarchy. It is a structural consequence of choosing department as the organizing principle. Every hierarchy you build makes the same trade: it optimizes for one axis of retrieval and degrades all others.
S. R. Ranganathan understood this in 1933 when he published his Colon Classification, the first fully faceted classification scheme. Working as a librarian in India, Ranganathan was frustrated by the Dewey Decimal Classification's insistence on a single hierarchical slot for every book. A book on the economic history of Indian agriculture in the nineteenth century genuinely belongs to economics, history, agriculture, India, and the nineteenth century — simultaneously. Ranganathan's solution was to decompose classification into five independent facets: Personality, Matter, Energy, Space, and Time. Each facet could be navigated independently, and any combination could be used for retrieval. The book did not have one location. It had a position in a five-dimensional space.
Ranganathan's insight was not merely technical. It was epistemic: the belief that any single hierarchy captures the "real" structure of knowledge is itself a failure of understanding. Knowledge is multidimensional. Hierarchies are one-dimensional projections. Multiple projections give you more of the truth than any single projection can.
The cognitive science of multiple categories
Your brain does not naturally organize the world into a single fixed taxonomy. Lawrence Barsalou demonstrated this in 1983 with his research on ad hoc categories — categories constructed on the fly to serve a goal. "Things to take on a camping trip," "things to sell at a garage sale," "foods to eat on a diet" — these are real categories that your mind constructs, uses, and discards as needed. They cut across every stable hierarchy you might have for the same items. A flashlight is "camping equipment" in one context, "things in the junk drawer" in another, and "emergency supplies" in a third. The item has not changed. The organizing principle has.
Gregory Murphy's foundational 2002 work The Big Book of Concepts reinforced this point: human conceptual structure is not a single taxonomy but a flexible, context-dependent system that can organize the same entities along multiple dimensions simultaneously. You do not have one mental hierarchy for food. You have several — by taste, by nutrition, by preparation method, by cultural origin, by personal preference — and you activate whichever one serves your current purpose.
This is not cognitive sloppiness. It is cognitive sophistication. A system that can reorganize the same data along different axes depending on the question being asked is more powerful than a system locked into a single fixed arrangement. Your brain already does this naturally. The problem is that your external tools — your folders, your outlines, your filing systems — often do not.
Faceted classification: the librarian's solution
The library science community has spent over a century grappling with this problem, and their solutions are directly applicable to personal knowledge organization.
Paul Otlet and Henri La Fontaine developed the Universal Decimal Classification (UDC) at the end of the nineteenth century, building on Dewey's system but adding synthetic capabilities — auxiliary signs and symbols that allowed a classifier to combine multiple facets into a single notation. A document could be marked as belonging to multiple subject areas, places, and time periods simultaneously.
The modern information architecture community formalized this further with the concept of polyhierarchy — a structure where a single item can have multiple parent categories. The Nielsen Norman Group identifies polyhierarchy as a key design pattern, noting that it accommodates the multiple mental models that different users have for the natural "home" of an item. A "wireless mouse" on an electronics store site genuinely belongs under both "Computer Accessories" and "Wireless Devices." Forcing it into one category penalizes every user whose mental model would have led them to the other.
Heather Hedden, author of The Accidental Taxonomist, notes that polyhierarchy in well-designed taxonomies typically involves only two broader concepts — rarely more — and requires that a term and all of its children can properly be assigned as a child of each parent. Not every item needs multiple parents. But the items that do are precisely the ones that become invisible when a strict single-parent hierarchy is enforced.
The ANSI/NISO Z39.19 and ISO 25964 standards for thesaurus construction explicitly support polyhierarchy across all three types of hierarchical relationship: generic-specific, generic-instance, and whole-part. These standards govern controlled vocabularies used in medicine, law, engineering, and government. The organizations that take knowledge organization most seriously have converged on the same conclusion: a single hierarchy is insufficient.
The matrix organization: multiple hierarchies in business
The corporate world discovered this principle independently through organizational design. A matrix organization is a structure in which people report to more than one authority simultaneously — typically a functional manager and a project manager.
Consider a software engineer on a cross-functional product team. In the functional hierarchy, she reports to the VP of Engineering. In the project hierarchy, she reports to the product lead for Mobile. In the geographic hierarchy, she belongs to the London office. These are three hierarchies of the same person, all organizationally real. Her skill development is governed by the functional hierarchy. Her daily work by the project hierarchy. Her office logistics by the geographic hierarchy.
The Project Management Institute traces matrix management back to the U.S. aerospace industry in the 1960s, when NASA programs required engineers from multiple functional departments to collaborate on specific missions. No single reporting hierarchy could simultaneously optimize for functional excellence, project delivery, and geographic coordination. Rather than choosing one and accepting the losses, organizations created multiple overlapping hierarchies and defined protocols for resolving conflicts between them.
Matrix organizations are difficult to manage. But that difficulty is not evidence that multiple hierarchies are wrong. It is evidence that multiple hierarchies create coordination costs — and that sometimes, the information preserved by multiple hierarchies is worth those costs.
Personal knowledge management: tags, folders, and maps of content
The personal knowledge management community has been fighting this battle for over a decade in the "tags versus folders" debate. The debate is a symptom of the deeper principle this lesson teaches.
Folders enforce a single hierarchy. Each note goes in exactly one folder. This is a tree. It makes certain retrievals fast and others impossible. Tags allow multiple categories per item. Each note can carry several tags. This is a step toward polyhierarchy — items can be found via any of their tags. But tags alone lack the hierarchical structure that makes navigation and progressive disclosure possible.
Nick Milo's Linking Your Thinking framework introduced Maps of Content (MOCs) as a third organizational mechanism. An MOC is a note that links to other notes, functioning as what Milo calls "a non-exclusive folder." A note can appear in multiple MOCs, just as a concept can have multiple parents in a lattice. But unlike flat tags, MOCs have structure — they can be annotated, ordered, and nested. They give you the multiple-parent capability of tags with the navigational structure of folders.
Tiago Forte's PARA system (Projects, Areas, Resources, Archives) takes a different approach: four top-level categories based on actionability rather than topic, with items moving between them as their actionability changes. PARA is not exactly multiple hierarchies of the same data — it is a single hierarchy with a dynamic assignment rule. But it acknowledges the core insight: the right place for an item depends on your current purpose, not on some inherent property of the item itself.
The most effective personal knowledge systems combine these mechanisms. Folders for coarse structure, tags for cross-cutting themes, links for semantic relationships, MOCs for curated entry points. Each is a different hierarchy of the same underlying content. Each makes different questions answerable.
AI and the Third Brain: simultaneous organizations without human overhead
Vector embeddings fundamentally change the economics of multiple hierarchies. In a traditional system, every hierarchy you maintain requires human effort — creating it, maintaining it, keeping it consistent as items are added and removed. The cost of maintaining three hierarchies is roughly three times the cost of maintaining one. This economic reality is why most people settle for a single hierarchy even when they know alternatives would be valuable.
Vector databases dissolve this constraint. When you embed your notes, documents, or concepts as vectors in a high-dimensional space, every item implicitly participates in an unlimited number of organizational schemes simultaneously. A query about "data migration strategies" will surface relevant items regardless of whether they were filed under Client A, Capability B, or Project C — because the vector representation captures semantic relationships that transcend any single hierarchical filing.
Retrieval-augmented generation (RAG) systems already operate this way. When you query a RAG-powered knowledge base, the system does not traverse a hierarchy. It computes similarity in embedding space, where the same document can be "near" documents from completely different hierarchical branches because they share semantic content. The hierarchy was never the ground truth. Meaning was. The hierarchy was a lossy approximation that human-scale cognition required because humans cannot compute similarity across thousands of items in real time.
AI tools that build on vector search give you something previously impossible: the ability to maintain the benefits of multiple hierarchies without the linear cost of maintaining each one manually. Your one hierarchy plus vector search is functionally equivalent to having dozens of hierarchies — because the vector space contains all of them implicitly.
The practical implication: do not abandon your primary hierarchy. It still serves as your navigational scaffolding and cognitive anchor. But stop believing it is the only valid organization. Use semantic search and AI-assisted discovery to access the other hierarchies that exist implicitly in your content. Let the machine compute the views you do not have time to maintain by hand.
Protocol: generating alternative hierarchies
This protocol helps you break out of hierarchy fixation by systematically constructing alternative organizations of the same data.
Step 1: Export your current hierarchy. Write down the top two levels of whatever organizational structure you use most — your notes, your project files, your skill inventory. This is Hierarchy A, your default.
Step 2: Identify the organizing principle. What dimension does Hierarchy A use? Topic? Project? Client? Date? Source? Write it down explicitly. "My notes are organized by topic area."
Step 3: List three alternative organizing principles. If your default is topic, your alternatives might be: by project relevance, by creation date, or by access frequency. If your default is client, try: by capability, by technology, or by team member.
Step 4: Build Hierarchy B. Take the same items and organize them using the first alternative principle. Do not just imagine it — actually write out the top two levels. You will immediately see items moving to surprising positions. Something buried three levels deep in Hierarchy A may appear at the top level in Hierarchy B.
Step 5: Identify the retrieval differences. For each hierarchy, write down three questions it answers instantly and three questions it cannot answer. Compare the lists. The questions that Hierarchy A cannot answer but Hierarchy B can are the blind spots in your default organization.
Step 6: Decide what to operationalize. You do not need to maintain every alternative hierarchy permanently. But you may discover that certain cross-cutting views are valuable enough to implement — as tags, as saved searches, as MOCs, or as periodic reorganization exercises. The goal is not to replace your default hierarchy. It is to know its limits and compensate for them deliberately.
The bridge to priorities
Once you see that multiple valid hierarchies exist for the same data, a new question becomes urgent: if you must choose a primary hierarchy — and in practice, you usually must — on what basis do you choose?
The answer is priorities. Your choice of organizing principle is a priority decision. When you organize projects by client, you are prioritizing client relationships over capability development. When you organize notes by topic, you are prioritizing conceptual coherence over chronological context. When you organize tasks by urgency, you are prioritizing responsiveness over strategic alignment.
These are not neutral, technical decisions. They are value decisions wearing the costume of information architecture. L-0276 examines this directly: hierarchies encode priorities. The top of your hierarchy is what you consider most important. The choice of which hierarchy to make primary reveals what you are optimizing for — and, by omission, what you are willing to lose.
Knowing that multiple hierarchies exist is the prerequisite for making that choice deliberately rather than by default.
Sources
- Ranganathan, S. R. (1933). Colon Classification. Madras Library Association.
- Otlet, P., & La Fontaine, H. (1905-1907). Universal Decimal Classification. Institut International de Bibliographie.
- Barsalou, L. W. (1983). Ad hoc categories. Memory & Cognition, 11(3), 211-227.
- Murphy, G. L. (2002). The Big Book of Concepts. MIT Press.
- Hedden, H. (2016). The Accidental Taxonomist (2nd ed.). Information Today.
- Nielsen Norman Group. (2024). Polyhierarchies Improve Findability for Ambiguous IA Categories. nngroup.com.
- Milo, N. (2021). In what ways can we form useful relationships between notes? Linking Your Thinking.
- Project Management Institute. (2023). The Matrix Organization. PMI Learning Library.
- ANSI/NISO Z39.19-2005 (R2010). Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies.