A taxonomy should make a complicated world easier to navigate, not make a simple list harder to use.
That sounds obvious. Yet many taxonomies fail in exactly the same way. They begin as neat trees, grow through years of exceptions, inherit labels from different teams, mix several dimensions, acquire duplicate branches, hide uncertainty, accumulate an enormous “Other” bucket and eventually require users to memorise the history of the system just to classify one new item.
A usable taxonomy needs more than good nouns. It needs architecture, criteria, governance and a method for change.
This article turns the general method from How to Categorise Anything into a build sequence.
Quick answer: how do you build a taxonomy?
- Define what the taxonomy must help people do.
- Define the objects being classified.
- Collect real examples before inventing the structure.
- Separate dimensions that answer different questions.
- Choose which dimension, if any, deserves a primary hierarchy.
- Use facets for dimensions that should combine freely.
- Write category definitions and admission rules.
- Choose the right granularity.
- Test with obvious cases, edge cases, hybrids and new cases.
- Measure classifier agreement and retrieval usefulness.
- Create identifiers, synonyms and controlled vocabulary.
- Define ownership, review and approval rules.
- Version changes and maintain crosswalks.
- Review “Other”, unclassified and disputed items as signals.
- Retire categories that no longer perform a useful job.
1. Begin with the retrieval or decision job
Do not open a blank document and start inventing category names.
First write the jobs the taxonomy must support.
- Find documents about the same subject.
- Route customer enquiries.
- Store goods safely.
- Compare cities.
- Teach students a concept hierarchy.
- Assign medical cases to specialist pathways.
- Describe museum objects.
- Group expenses for reporting.
- Map research literature.
- Organise a website.
- Let an AI system select the right domain or tool.
Different jobs produce different taxonomies. A library and a warehouse may classify the same object differently because one optimises retrieval while the other optimises handling.
The purpose statement should be specific enough that you can later ask: Did the taxonomy improve the job?
2. Define the scope
Every taxonomy needs a boundary.
Write what is in scope, what is out of scope and which adjacent systems will remain separate.
If you are building a taxonomy of books, are you classifying intellectual works, editions, physical copies, authors, publishers or subjects? If you are classifying companies, are you describing legal entities, brands, business units, industries, products or ownership groups?
A taxonomy becomes unstable when its object type changes halfway down the tree.
3. Define the unit of classification
The unit is the thing that receives the category.
This sounds trivial until a project mixes:
- people with roles;
- organisations with buildings;
- diseases with symptoms;
- documents with subjects;
- products with product features;
- events with causes;
- places with activities performed there.
Use separate entity types where needed. A relationship between two entity types is usually clearer than forcing one into the other’s hierarchy.
4. Collect real examples before designing categories
Taxonomies designed from imagination often fit the examples the designer remembered and fail on the examples the world actually contains.
Collect a representative sample. Include:
- common items;
- rare items;
- high-value items;
- high-risk items;
- old records;
- new records;
- items users frequently misclassify;
- known exceptions;
- items currently stored in “Other”.
The sample is your first reality check.
5. Study the language people already use
Existing language contains useful evidence, even when it is inconsistent.
Collect search terms, folder names, spreadsheet headings, team vocabulary, abbreviations, legacy codes, customer language and specialist terminology.
Do not automatically preserve every old label. The goal is to understand the language environment so the new taxonomy can map between expert terms, common terms and historical terms.
6. Identify the dimensions hiding inside the labels
Suppose an old folder system contains:
- Singapore;
- Reports;
- Urgent;
- Finance;
- 2025;
- PDF;
- Internal.
These are not seven sibling topics. They represent different dimensions:
- place;
- document type;
- priority;
- subject;
- time;
- format;
- access status.
This is one of the highest-leverage taxonomy moves: separate the axes before arranging the labels.
7. Decide whether you need one primary hierarchy
A primary hierarchy is useful when users need one stable route or when one “is a” relationship genuinely dominates the domain.
Examples include biological taxonomic levels, organisational reporting structures, geographic containment or product family hierarchies.
But do not create a primary hierarchy merely because tree diagrams look orderly. If several dimensions are equally important, a faceted architecture may be better.
8. Use “is a” carefully
A taxonomy branch should usually preserve one semantic relationship.
If “electric car” is a kind of car, that is an “is a” relationship. “Battery” is part of an electric car. “Charging” is an activity. “Singapore” is a location. “Private ownership” is an ownership state.
Do not force part-of, used-for, located-in and owned-by relationships into the type tree.
The moment a hierarchy mixes relationship types, users stop knowing what parenthood means.
9. Use facets for independent dimensions
Facets allow one item to be described along several independent axes.
A research paper could receive:
- Subject: climate science;
- Place: Southeast Asia;
- Method: remote sensing;
- Document type: journal article;
- Audience: specialist;
- Language: English;
- Date: 2026.
Users can then combine facets during retrieval rather than navigating one enormous pre-combined tree.
10. Decide which labels are categories and which are attributes
Not every descriptive fact deserves a taxonomy node.
Colour, exact weight, publication date, serial number, owner name or measured temperature may be better represented as metadata fields. A taxonomy is most useful for recurring controlled values that support grouping and navigation.
This keeps the tree from exploding.
11. Write definitions before arguing about names
Teams often spend hours debating labels while assuming they agree on meaning.
Reverse the order. Write the category definition first.
For each category, define:
- what it means;
- why it exists;
- what must be true for membership;
- what excludes membership;
- examples;
- counterexamples;
- known edge cases.
Once the meaning is stable, choose the clearest name.
12. Create preferred terms and synonyms
Real users do not all use the preferred label.
A controlled vocabulary should distinguish:
- preferred term — the canonical display label;
- synonyms — alternative names;
- abbreviations — accepted shortened forms;
- legacy terms — old names users may still search;
- misspellings — optionally captured for search, not display;
- related terms — concepts that should not be treated as synonyms.
This is especially valuable for libraries, archives, websites and AI retrieval systems.
13. Give categories stable identifiers
Names change. Identifiers should change less often.
A stable category ID allows “Human Resources”, “People Operations” and “HR” to refer to one underlying concept across renames.
Stable IDs also make crosswalks, historical records and software integrations safer.
14. Choose the right depth
Deep hierarchies create precision and navigation cost.
A hierarchy with twelve levels may be scientifically defensible and operationally exhausting. A hierarchy with two levels may be easy to learn and useless for retrieval.
Choose depth based on decisions and search behaviour, not aesthetic symmetry.
15. Choose sibling categories at comparable resolution
A common taxonomy smell is uneven resolution.
Imagine siblings called “Animals”, “Rose”, “Oak Trees” and “Microorganisms”. One branch is extremely broad, another is a species-level concept, another is a group of trees and another spans multiple biological kingdoms.
Siblings do not need identical size, but they should usually answer the same kind of question at roughly compatible resolution.
16. Avoid catch-all branches that hide design debt
“Miscellaneous”, “General”, “Other”, “Special”, “Uncategorised” and “Various” are sometimes necessary. They should be monitored.
A catch-all category should have an explicit rule and a review threshold. For example: if more than 10% of new items enter “Other”, inspect the contents for emerging categories.
The precise threshold depends on the domain. The principle is universal: unstructured accumulation is feedback.
17. Allow multiple classification where the job needs it
A single-primary-category rule can simplify reporting, but it may damage retrieval.
Decide explicitly whether an item may have:
- one primary category only;
- one primary plus secondary categories;
- multiple equal categories;
- one value per facet;
- multiple values per facet.
The data model should reflect the real rule instead of forcing users to invent workarounds.
18. Separate lifecycle state from taxonomy
Active, inactive, draft, approved, archived, retired and deleted are usually states. They should not be mixed into the type hierarchy unless the type itself changes.
This makes change easier to record and historical queries easier to answer.
19. Represent uncertainty explicitly
A taxonomy is safer when it can say:
- provisional;
- low confidence;
- disputed;
- insufficient evidence;
- awaiting review;
- not applicable.
Without these states, users are pushed toward false certainty or misuse of “Other”.
20. Create category cards
Every important category should have a specification that survives beyond the person who invented it.
- ID
- preferred label
- definition
- purpose
- dimension
- parent
- synonyms
- admission rule
- exclusion rule
- examples
- counterexamples
- edge cases
- owner
- version
- review date
That card becomes the operating memory of the taxonomy.
21. Build with examples, not only definitions
Definitions tell users the rule. Examples show what the rule looks like in the world.
For each category, include:
- two or three obvious examples;
- one near miss;
- one edge case;
- one confusing sibling comparison.
For teaching, training and AI evaluation, contrasting examples are especially valuable because they reveal the discriminating feature.
22. Run a card-sorting test
Give representative items to several users and ask them to group or classify them without coaching.
Observe:
- which groupings emerge naturally;
- which labels users misunderstand;
- where they hesitate;
- which items attract several plausible homes;
- which dimensions users mix.
The goal is not to let users vote the taxonomy into existence. It is to expose mismatches between conceptual architecture and real usage.
23. Test classification agreement
Give the same labelled scheme and sample items to independent classifiers.
High disagreement may indicate:
- unclear definitions;
- overlapping sibling categories;
- missing evidence;
- too much required subject expertise;
- poor training examples;
- genuinely ambiguous reality.
Measure disagreement by category, not only overall. A taxonomy can look reliable on average while one crucial branch remains unstable.
24. Test retrieval, not only classification
A taxonomy can classify consistently and still be poor at helping people find things.
Create realistic retrieval tasks:
- Find all reports about flood risk in Southeast Asia.
- Find every archived contract relating to one supplier.
- Find every article suitable for a Secondary student studying genetics.
- Find equipment requiring refrigerated storage.
Measure whether users can retrieve the right set quickly and whether relevant items are missed.
25. Test future cases
A taxonomy must survive objects that did not exist when it was designed.
Ask:
- Where would a hybrid product go?
- What if an item serves three functions?
- What if a new technology creates a new mechanism?
- What if the organisation expands to a new country?
- What if legal definitions change?
- What if an AI-generated object has no traditional author?
The purpose is not to predict every future. It is to reveal whether the architecture has room to grow without breaking its own logic.
26. Govern who can change the taxonomy
If everyone can change the taxonomy, it drifts. If nobody can change it, it freezes.
Define roles:
- users who apply categories;
- stewards who review problems;
- domain experts who validate meaning;
- owners who approve structural changes;
- system maintainers who implement changes.
A change workflow protects consistency while allowing learning.
27. Make change requests evidence-based
A new category should not be created merely because one unusual item arrived.
A good change request states:
- the problem;
- examples affected;
- current workaround;
- proposed category or change;
- expected benefit;
- possible collisions;
- migration impact;
- who needs to approve.
That makes taxonomy growth intentional.
28. Version every structural change
A taxonomy is a time-varying model.
When categories are split, merged, renamed, moved or retired, store the version and effective date.
Do not simply edit history. Old records may need to be interpreted according to the scheme that existed when they were classified.
29. Maintain crosswalks between versions
A crosswalk states how an old category relates to a new one.
- same as
- broader than
- narrower than
- split into
- merged into
- related to
- retired with no direct replacement
Crosswalks preserve continuity across time and allow data from several systems to remain comparable.
This is central to the World Knowledge Research Library Projection: knowledge systems should be able to meet without pretending they were built from the same schema.
30. Crosswalk between external taxonomies carefully
Two organisations may use the same word differently or different words for the same concept.
Never map labels by spelling alone.
Compare definitions, scope, time period, authority and granularity. A one-to-one mapping is ideal when true, but many real mappings are one-to-many, many-to-one or only approximate.
31. Separate canonical taxonomy from local views
Different teams may need different navigation without creating different underlying meanings.
Keep a canonical concept layer with stable IDs, then allow local views, filters or menus to present those concepts differently.
This reduces duplicate categories and preserves interoperability.
32. Do not make the taxonomy carry the entire knowledge graph
Taxonomies are excellent for type and grouping relationships. They are not the ideal representation for every connection.
Use typed relationships for facts such as:
- authored by;
- located in;
- caused by;
- treats;
- part of;
- owned by;
- depends on;
- supports;
- contradicts;
- derived from.
A knowledge architecture is usually stronger when taxonomy, metadata and relationships each do the job they are best at.
33. Build for human recognition
A theoretically perfect category name that users do not understand is not operationally perfect.
Use clear labels, plain definitions, examples and visible hierarchy. Keep expert terminology where precision demands it, but provide synonyms and explanations.
The interface between human and taxonomy is part of the taxonomy system.
34. Build for machines without making humans disappear
Machine-readable taxonomy needs stable identifiers, explicit relations, versioning, validation and predictable data types.
AI can help classify new items, but it should receive the same category definitions, evidence rules and uncertainty states that human classifiers use.
For consequential classifications, preserve the evidence and confidence so machine decisions can be reviewed.
35. Monitor taxonomy health
A taxonomy can be measured.
- Percentage of items in “Other”.
- Percentage unclassified.
- Classifier disagreement rate.
- Search failure rate.
- Number of duplicate or near-duplicate categories.
- Average depth used.
- Categories with zero or almost zero members.
- Categories growing unusually fast.
- Time taken to classify.
- Number of manual exceptions.
- Number of change requests.
These metrics turn taxonomy maintenance from opinion into diagnosis.
36. Know when to split a category
Split when a broad category contains stable subgroups that support meaningfully different retrieval, explanation or action.
Do not split merely because many items exist. A large coherent category can remain useful.
37. Know when to merge categories
Merge when categories repeatedly confuse users, have indistinguishable criteria, lead to the same actions and do not add useful retrieval precision.
Before merging, check whether historical or legal differences still matter.
38. Know when to retire a category
Retirement is better than deletion when records already depend on a category.
Mark the category as no longer available for new classifications, preserve its definition and map it to successor categories where possible.
A taxonomy should remember the structures it once used.
39. A complete taxonomy build checklist
- Purpose written.
- Scope written.
- Entity types defined.
- Representative sample collected.
- Existing language collected.
- Dimensions separated.
- Primary hierarchy justified.
- Facets identified.
- Attributes separated from categories.
- Category definitions written.
- Preferred labels and synonyms set.
- Stable IDs assigned.
- Granularity reviewed.
- Sibling consistency reviewed.
- “Other” rule defined.
- Multiple-membership rule defined.
- Uncertainty states defined.
- Examples and counterexamples added.
- Card sorting completed.
- Agreement testing completed.
- Retrieval testing completed.
- Future-case testing completed.
- Owners and stewards assigned.
- Change process written.
- Versioning enabled.
- Crosswalk format defined.
- Health metrics selected.
- Review cadence established.
40. The taxonomy should disappear into the work
The best taxonomy is rarely the one users admire most.
It is the one they can use without fighting it.
Search becomes faster. Similar cases sit together. Exceptions are visible. New items have a plausible home. Reports mean the same thing next year. Systems can exchange data. AI can route more reliably. People spend less time debating folders and more time doing the real job.
That is when taxonomy becomes infrastructure.
Final answer
Build a taxonomy from reality outward. Define the job and the object. Collect real examples. Separate dimensions. Use hierarchy only where the relationship is truly hierarchical. Use facets when several independent axes matter. Give categories definitions, criteria, synonyms and stable identifiers. Test the system with edge cases and retrieval tasks. Govern changes. Version the schema. Maintain crosswalks.
A taxonomy is finished only temporarily. Its real quality appears in how well it can change without forgetting what it used to mean.