Every useful system of categories eventually becomes a tree.
You already know how to classify things. The previous lessons in this phase established that classification is constructed, that explicit categories beat implicit ones, that binary categories lose information, and that spectrums preserve nuance. But flat classification — all categories at the same level — stops scaling the moment your collection grows past a few dozen items.
Try organizing 500 bookmarks with flat tags. Or 2,000 notes with single-level folders. Or the 1.5 million known animal species with a simple list. It doesn't work. You need structure inside the structure. You need categories that contain other categories, arranged from the general to the specific, each level inheriting context from the one above.
That structure is a taxonomy: a hierarchical classification system where every item belongs to a parent category, which belongs to its own parent, all the way up to the root. Taxonomy design is the skill of deciding how many levels to create, where to draw the boundaries, and which level carries the most operational weight.
Linnaeus and the original hierarchy
The most famous taxonomy in history is biological. In 1735, Carl Linnaeus published Systema Naturae, which organized all known living things into a nested hierarchy: Kingdom, Class, Order, Genus, Species. Before Linnaeus, naturalists used long, irregular Latin descriptions to identify organisms — a single plant might carry a twelve-word name that varied from one scientist to the next. Linnaeus replaced this chaos with a two-word system (binomial nomenclature) embedded in a strict hierarchy: every species belonged to exactly one genus, every genus to one order, every order to one class.
The insight was not that living things could be grouped — Aristotle had done that two thousand years earlier. The insight was that nesting creates navigability. If you know an organism is in the class Mammalia, you already know it is warm-blooded, has hair, and nurses its young — without checking the individual species description. Each level of the hierarchy carries inherited information downward, which means you don't need to redescribe every attribute at every level.
This is the fundamental value proposition of any taxonomy: inheritance reduces redundancy. A child category inherits the properties of its parent. You define "mammal" once at the class level, and every species beneath it carries those properties automatically. This is the same principle that drives class hierarchies in object-oriented programming, folder structures in file systems, and topic trees in knowledge management.
How libraries tamed the universe of knowledge
Libraries faced the same scaling problem that Linnaeus faced with species. Melvil Dewey's 1876 Decimal Classification system solved it with a strictly hierarchical numeric scheme: ten top-level classes (000-999), each divided into ten divisions, each divided into ten sections, with decimals for further specificity. The number 636.7 means "Technology" (600) > "Agriculture" (630) > "Animal husbandry" (636) > "Dogs" (.7). Every digit narrows the scope.
The Library of Congress Classification, developed in the late nineteenth century, used a similar hierarchical approach with letter-number combinations — 21 top-level classes, each subdividing into increasingly specific topics. Both systems share a design principle: you should be able to locate any item by navigating from broad to narrow, level by level, without needing to know the item's specific identifier in advance.
These library systems also reveal a persistent tension in taxonomy design. The Dewey system tries to classify all knowledge into a predetermined hierarchy, which means new fields (computer science, for instance, didn't exist in 1876) must be awkwardly wedged into categories designed for a different era. The Library of Congress system, designed to classify a specific physical collection, is more pragmatic but less portable. Every taxonomy embeds assumptions about what the world contains and how it divides — and those assumptions age.
Your brain prefers a specific level of hierarchy
Not all levels of a taxonomy are equal in your mind. In the 1970s, cognitive psychologist Eleanor Rosch conducted a series of experiments that revealed something counterintuitive about how humans process hierarchical categories.
Rosch showed participants pictures of objects and asked them to provide the first name that came to mind. Out of 1,595 responses, almost all used what she called the basic level — "chair," "dog," "car." Almost no one said the superordinate ("furniture," "animal," "vehicle"), and almost no one said the subordinate ("kitchen chair," "golden retriever," "sedan"). When asked to verify category membership as quickly as possible, participants were fastest at the basic level.
The basic level is where the hierarchy is most useful to you. It is the level at which category members share the most distinctive features, where you can form a mental image, and where your motor programs align (you "sit in a chair" but don't "sit in furniture"). Rosch and Mervis (1975) showed that basic-level categories have the highest cue validity — the probability that an object with a feature belongs to that category.
This has a direct implication for taxonomy design: your working taxonomy should be optimized at the basic level. That means the categories you browse, tag with, and navigate daily should sit at the level where you naturally think — not too broad (you'll lump unlike things together) and not too narrow (you'll create distinctions you can't remember). The superordinate level above provides context. The subordinate level below provides precision when you need it. But the basic level is where you live.
Simon's architecture: why hierarchies survive
Why do taxonomies tend to be hierarchical in the first place? Herbert Simon addressed this directly in his 1962 paper "The Architecture of Complexity." His argument is evolutionary: hierarchical systems assemble faster and survive longer than non-hierarchical ones.
Simon's parable of the two watchmakers illustrates the point. Tempus builds watches from 1,000 parts, assembling all at once. If he is interrupted (a phone call, a dropped component), the entire assembly falls apart and he must start over. Hora builds watches from sub-assemblies of 10 parts each, which combine into larger assemblies of 10 sub-assemblies, which form the final watch. When Hora is interrupted, he loses only the sub-assembly in progress. Hora finishes watches orders of magnitude faster than Tempus.
The lesson generalizes: complex systems that are nearly decomposable — organized into semi-independent subsystems with strong internal connections and weak external ones — evolve more rapidly and are more resilient to disruption. This is why biological organisms are hierarchical (cells, tissues, organs, systems). It is why organizations are hierarchical (teams, departments, divisions). And it is why your knowledge system, if it is going to scale, needs hierarchy.
Near-decomposability also explains why good taxonomies feel natural. The items within a category interact with each other more than with items in sibling categories. "Dogs" and "cats" live under "pets" because the knowledge you need about pet care clusters together — feeding, veterinary visits, shelter — in ways that overlap more within the group than across the boundary to, say, "power tools."
Miller's chunking: hierarchy as a compression strategy
George Miller's famous 1956 paper established that working memory holds roughly seven items (plus or minus two) at a time. But Miller's deeper insight was about chunking: you can expand your effective capacity by grouping items into meaningful units and then grouping those units into larger units.
Miller illustrated this with a telegraph operator learning Morse code. At first, each dit and dah is a separate chunk. Then letters become chunks. Then words. Then phrases. Each level of chunking is a level of hierarchy, and each level lets you process more information without exceeding your cognitive capacity.
Taxonomy is chunking made explicit. When you organize 200 notes into 8 categories, you've replaced 200 items with 8 chunks. When you organize those 8 categories under 3 superordinate headings, you've replaced 8 items with 3. You can hold the top level in working memory — "I'm looking for something in Science, not Arts or Projects" — and then drill into the sub-level, which also stays within working memory because it contains fewer than seven items.
This is why practical taxonomy design follows a rule of thumb: no more than seven children per parent node. Exceed that, and you lose the chunking advantage — the level becomes too large to scan without cognitive overflow.
When hierarchy fails: the limits of trees
Taxonomies are powerful, but they have a structural limitation: every item gets exactly one parent. A tree is a strict hierarchy — no node has two parents, no item belongs to two branches simultaneously.
Reality is not always so clean. Is a "smart speaker" a piece of consumer electronics or a home automation device? Is a blog post about machine learning in healthcare filed under "AI" or under "Medicine"? The moment an item legitimately belongs in two places, a strict taxonomy forces a choice — and that choice loses information.
Software engineering encountered this problem directly. Object-oriented programming's class hierarchies — the "is-a" relationship — initially seemed like the natural way to model the world. But deep inheritance hierarchies created brittle systems. Changes to a base class rippled unpredictably through dozens of subclasses. An object that needed behaviors from two different branches of the hierarchy couldn't inherit from both (in most languages). The Gang of Four design patterns book captured the hard-won lesson: "Favor composition over inheritance" — meaning, don't force everything into a tree if the underlying reality is a graph.
S.R. Ranganathan, an Indian mathematician and librarian, anticipated this problem decades earlier with his faceted classification system. Instead of filing a book into one branch of a single hierarchy, Ranganathan proposed classifying it along multiple independent dimensions — personality, material, energy, space, and time. A book on "the heat treatment of steel in nineteenth-century England" could be found via any of those facets, not just the one slot where a hierarchical system would have placed it.
The practical lesson: use hierarchy as your primary navigation structure, but layer facets, tags, or cross-references on top to handle the cases where items genuinely span boundaries. A taxonomy gives you the speed of top-down navigation. Tags and facets give you the flexibility of multi-dimensional access. The combination is more powerful than either alone.
AI and the Third Brain: hierarchies as machine-readable scaffolding
When an AI system needs to reason about your knowledge, hierarchy is what makes that reasoning possible.
In the semantic web, the Web Ontology Language (OWL) builds on exactly this principle. OWL defines classes in hierarchical relationships — Dog is a subclass of Mammal, which is a subclass of Animal — and then uses those relationships to infer properties automatically. If you tell the system that all mammals are warm-blooded and that a dog is a mammal, it can conclude that a dog is warm-blooded without being told explicitly. This is inheritance at machine scale.
Knowledge graphs — the structures powering everything from Google's search results to enterprise AI systems — rely on taxonomic hierarchies as their backbone. A taxonomy provides the vocabulary (what types of things exist), while the knowledge graph provides the instances (which specific things exist and how they relate). Without the hierarchical scaffolding, the knowledge graph is an unstructured heap of facts.
For your personal cognitive infrastructure, this means that a well-designed taxonomy doesn't just help you navigate your knowledge — it helps any AI tool you use understand the structure of what you know. When your notes are organized hierarchically with clear parent-child relationships, an AI assistant can traverse that structure, find relevant context, and make connections across branches. When your notes are a flat pile of documents, the AI is reduced to keyword search — powerful, but blind to the relationships between your ideas.
The taxonomy is the skeleton that gives your knowledge system shape. AI can add muscle and speed, but only if the skeleton is there.
A protocol for building your own taxonomy
Here is a repeatable process for designing a taxonomy for any domain in your life — notes, projects, skills, reading, or anything else that accumulates and needs structure.
Step 1: Dump everything flat. Start with every item, tag, or category you currently have. Don't organize yet. Just list them.
Step 2: Find the basic level. Look at your list and identify the level at which you naturally think. These are the categories you'd use if someone asked "what kind of thing is this?" without pressing for more detail. "Psychology," not "Science." "React project," not "Code." Those are your basic-level categories.
Step 3: Group upward. Cluster your basic-level categories into three to five superordinate groups. These become your top-level navigation. If you can't find a natural grouping, you may have too many basic-level categories — some of them are probably subordinate-level items masquerading as peers.
Step 4: Split downward only where needed. Add subordinate categories only when a basic-level category grows large enough that you can't scan it quickly (roughly more than 20-30 items). Don't pre-create subordinate categories "just in case." Let them emerge from actual use.
Step 5: Enforce the seven-child rule. No parent should have more than seven children. If it does, you likely need an intermediate level — or some of those children are actually peers at a different level of abstraction.
Step 6: Add facets for cross-cutting concerns. If an item legitimately belongs in two branches, don't duplicate it. Instead, add a tag, metadata field, or cross-reference that captures the second dimension. The taxonomy handles primary navigation; facets handle secondary access.
Step 7: Review quarterly. A taxonomy is a living structure. As your collection grows, some branches become overcrowded while others remain empty. Prune the empty branches. Split the overcrowded ones. Move items that ended up in the wrong spot. This is not failure — this is maintenance, and it's what keeps the system useful.
The taxonomy is the spine
Classification without hierarchy is a list. It works for 20 items. It breaks at 200 and is useless at 2,000. Hierarchy solves the scaling problem by imposing structure at multiple levels, each one compressing the complexity of the level below it into a manageable number of chunks.
But hierarchy is a tool, not a truth. The tree structure is an approximation of reality — useful, navigable, and fast, but necessarily lossy. Some things genuinely belong in two places. Some categories will need to be refactored as your understanding deepens. The skill is not building the perfect taxonomy on the first attempt. The skill is building one that's good enough to navigate today and flexible enough to evolve tomorrow.
The next lesson takes this further: once you have a hierarchy, how do you ensure that the categories at each level don't overlap and don't leave gaps? That's the MECE principle — mutually exclusive, collectively exhaustive — and it's what turns a rough taxonomy into a rigorous one.