The 18-Month Test

A taxonomy that works today and breaks in 18 months is a liability, not an asset. The 18-month test is a design heuristic: before finalizing any structural decision, project the knowledge base forward 18 months — more content, more contributors, more teams, possibly new product lines or service areas — and ask whether the structure still works.

Most taxonomy failures are visible in the 18-month projection but invisible at launch. The category that contains 12 items today will contain 200 in 18 months. Does the name still make sense? Does the boundary still hold? Does the depth level still support navigation? These questions are cheap to answer in design and expensive to answer in migration.

1. Project Content Volume Estimate growth: how many new items will be added per month? At that rate, which categories will become unmanageably large? A category with 15 items today and 10 added per month has 195 items in 18 months. That is a category that either needs subcategories now or will need them urgently later. Design the subdivision path before the pressure arrives.
2. Project Contributor Count A taxonomy maintained by one person has different tolerance for ambiguity than one maintained by 25. Ambiguous category boundaries that one person resolves consistently in their head become inconsistency at scale. The 18-month test for contributor count: if 20 people used this taxonomy independently, how many would classify the same item the same way? If the answer is "fewer than 15," the boundary needs sharpening.
3. Stress-Test Category Boundaries Take 20 representative items from across the knowledge base and ask where each one belongs. Items that provoke genuine debate about their category are revealing taxonomy gaps. Document those debates — they identify the categories that will accumulate misclassification errors at scale. Resolve ambiguity in the governance documentation, not in individual contributors' heads.
4. Design Subdivision Paths For every category likely to grow large, plan the subdivision path in advance. If "API Documentation" reaches 150 items, it might split into "REST API Reference," "Authentication," "Webhooks," and "SDKs." Knowing this in advance means the split can happen gracefully rather than as an emergency refactor when navigation has already broken down.