KM-301a · Module 1
Flat vs. Hierarchical vs. Faceted
5 min read
Taxonomy is the foundational decision in knowledge architecture. Get it wrong and every retrieval problem downstream is harder than it needs to be. There are three structural patterns. Each has a distinct use case and a distinct failure mode. The mistake is not choosing the wrong one — the mistake is not knowing you chose at all.
Flat taxonomies have no hierarchy: every item exists at the same level, classified by tags or labels without parent-child relationships. Hierarchical taxonomies nest items in a tree: categories contain subcategories contain items. Faceted taxonomies classify items along multiple independent dimensions simultaneously — an item can be tagged with a product type, a customer segment, and a process phase without any of those dimensions being subordinate to the others.
- Flat Taxonomy Best fit: small, stable knowledge bases with homogeneous content. Under 200 items where categories are obvious and unlikely to proliferate. Works well for simple FAQ repositories or a single team's runbook collection. Collapses when the item count grows beyond what a single list can communicate — users start asking "where do I even look?" and the answer is "everywhere, good luck."
- Hierarchical Taxonomy Best fit: knowledge bases with clear parent-child relationships in the domain itself — technical documentation where product → module → feature is a natural and stable structure. Works well when the hierarchy reflects how users think about the domain, not just how the team organized the content. Collapses when items legitimately belong in multiple branches, or when the hierarchy deepens past four levels and users lose their orientation.
- Faceted Taxonomy Best fit: complex domains where content legitimately belongs to multiple categories simultaneously. A runbook for resetting AWS credentials during an SOC 2 audit is simultaneously: Infrastructure (topic), Incident Response (process phase), Compliance (domain), and Tier 1 (complexity). Flat and hierarchical structures force an arbitrary primary home. Faceted classification reflects the multi-dimensional reality. Collapses when facets are poorly defined and overlap, or when the number of facets grows without governance.
Do This
- Audit how users actually search before choosing a pattern — search behavior reveals natural dimensions
- Choose faceted when content legitimately belongs in more than one category
- Choose hierarchical when the domain has a natural, stable tree structure
- Choose flat only for genuinely small, homogeneous collections
Avoid This
- Default to hierarchical because it looks organized — hierarchies add navigation overhead
- Build a faceted system without first defining what a facet is and is not
- Mix patterns without documenting which applies to which content type
- Let the taxonomy pattern be an implicit decision made by whoever built the first folder