NOT.03 · Notes · 12 October 2026
Why one tree cannot answer two questions
On the single most common structural flaw in product and editorial taxonomies — gluing independent dimensions into one dropdown — and the two clean ways to fix it.
In classical logic, the rule of division is simple: at any single step of a hierarchy, a set must be divided by one and only one characteristic (fundamentum divisionis). In a kickoff workshop, everyone nods in agreement. In a production database, almost every category tree violates that rule by the second level down.
Look at a typical menu in a corporate intranet, product catalogue or report repository: sitting side by side as siblings in a single dropdown are “Quarterly reports” (format and cadence), “Security” (subject), “Executive board” (audience) and “Urgent” (workflow state). As long as a document is a routine memo about nothing in particular, nobody notices. The moment someone has to file an urgent quarterly security report for the executive board, the UI forces them to pick one truth and throw away the other three.
How tangled trees happen
Tangled axes of division rarely come from ignorance. More often they are the geological sediment of organisational history:
- The first team needed a breakdown by entity type (what the thing is).
- A second team appended three items by purpose (what the thing is used for) to the same list because the CMS form only had one category field and adding a second field required engineering time.
- A third team added a bucket based on market salience (“Core”, “Trending”, “Strategic”) because they wanted a quick filter for a landing page.
Twelve months later, the dropdown holds twenty options that look like peers on screen, but are actually four separate vocabularies tipped into a single bin.
If two sibling categories cannot answer the exact same “divided by what?” question, they are not neighbours in a single tree — they are values from two different dimensions.
Two ways out: facet decomposition or a gate cascade
When an audit uncovers a tangled tree, there are two clean architectural fixes, depending on what the downstream system needs:
- Splitting into independent facets (multi-axis modelling). When an object genuinely has several independent dimensions that matter simultaneously for retrieval or analysis, each dimension gets its own axis with a small, closed set of values. In the psychological games taxonomy, separating category (what the object is) from mechanism (why it works) immediately resolved disputes over items that combined an interpersonal game with a cognitive bias. In the violent-death model, replacing a single “manner of death” label with six independent axes (unit of analysis, agency, intent, consent, institutional mandate, causal role) made it possible to describe borderline cases where single-slot classifications have broken down since the nineteenth century.
- A lexicographic gate cascade with yes/no rules. Sometimes the target system (a URL structure, a primary folder, or process ownership) genuinely requires one primary home per item. Rather than pretending the characteristics are naturally disjoint, you establish an explicit precedence order of gates. In the web project taxonomy, that role is played by the
N > P > O > Rkey: first ask whether core value depends on a network of autonomous participants (N); if not, whether it requires a persistent workspace across sessions (P); if not, whether it binds the operator to fulfil an obligation (O); if not, whether it provides an interactive session runtime (R); otherwise it falls back to publishing. An item exhibiting multiple traits always enters the first gate it satisfies, while secondary traits are recorded explicitly as secondary contracts instead of vanishing.
A sixty-second diagnostic test
Pick any five sibling categories sitting at the same level of your taxonomy and complete the sentence: “Every item at this level differs from its neighbours solely by [X]”. If filling in [X] requires the word “or” (“by topic or format or department”), you are looking at a tangled tree.