The first time I broke a downstream report by renaming a taxonomy term, it was a Tuesday and the report was a board pack. The term had been called “Customer (Active)” for years and someone — me — decided it would be cleaner as just “Active Customer.” The change went through the steward’s review queue, looked harmless, got approved. The board pack on Friday had a row that said “Active Customer” where every previous quarter’s pack had said “Customer (Active).” A board member asked, politely, what had changed in the definition. The answer was nothing. Only the label had changed. It still took an hour of explanation and a written follow-up.

Taxonomy versioning sits in this awkward middle ground between data engineering and library science, and most teams treat it with neither discipline’s rigour. The cost shows up later, usually as the kind of trust erosion that’s hard to recover from.

The three things that change in a taxonomy

To version a vocabulary sensibly, you have to be precise about what’s actually changing. There are really three different operations and they have very different consequences.

The first is a label change — the preferred term is renamed, but the underlying concept is the same. Customer (Active) becomes Active Customer. The semantics are unchanged, the URI or identifier should not change, and downstream systems that pull by ID won’t notice. Downstream systems that pull by label (which they shouldn’t, but they often do) will break.

The second is a scope change — the concept’s definition is broadened or narrowed. “Active Customer” used to mean “purchased in the last 12 months” and now means “purchased in the last 6 months OR has an active subscription.” The label might not change, the identifier won’t change, but every historical comparison just became misleading. This is the dangerous one. It’s also the one that gets logged least carefully.

The third is a structural change — concepts are split, merged, moved in the hierarchy, or deprecated. “Active Customer” is split into “Transacting Customer” and “Subscribing Customer.” The old concept ceases to exist, two new concepts come into being, and any historical data tagged with the old concept needs a migration story.

Why most teams version badly

The most common pattern I see is a single “current” version of the taxonomy with a change log that nobody reads, served from a wiki or a SharePoint document. Changes get made, the change log gets updated (sometimes), and downstream consumers find out about changes through the medium of breakage.

Slightly more mature teams have semantic versioning on the taxonomy as a whole — v2.3.1, that kind of thing — but apply it with no real discipline about what makes a major versus a minor versus a patch change. Without that discipline, versioning is theatre.

The mature pattern, which is rare but worth aspiring to, treats a taxonomy as a versioned artifact with the same care you’d give a public API. Each concept has a stable identifier that never changes once published. Each concept has a versioned history of its label, definition, scope notes, and parent. Deprecation is explicit, with a sunset date and a recommended successor. Change announcements go to subscribers, not just to the change log.

The W3C’s SKOS recommendation provides a reasonable foundation for this — skos:Concept, skos:prefLabel, skos:historyNote and so on — and the W3C SKOS reference is still the right starting point in 2026 for teams who want a published vocabulary that doesn’t need to be reinvented. The mistake teams make is treating SKOS as the modelling answer when it’s really just the format. The discipline still has to come from the team.

What “good enough” actually looks like

Not every organisation needs a full SKOS-based taxonomy management platform. For most enterprise teams, a workable versioning approach has roughly these components:

• Stable internal identifiers separate from labels. The label can change. The ID cannot. Every system that integrates with the taxonomy should integrate by ID, with the label being a display concern only. This is the single biggest change that prevents the Friday-board-pack problem.

• A defined release cadence. A taxonomy that changes daily without batching is hostile to its consumers. A reasonable cadence is monthly or quarterly, with an emergency lane for urgent corrections. Within the cadence, all changes go out together and downstream consumers know when to look.

• A clear definition of what triggers each version-bump. Patch: typo or label correction. Minor: new concept added, scope broadened, non-breaking. Major: scope narrowed, concept split or merged, anything historical comparisons would care about. Anyone can disagree about the exact boundaries; the important thing is that your team has agreed and applies the rule consistently.

• A deprecation policy with teeth. Concepts don’t get deleted; they get marked deprecated with a successor and a sunset date, and the sunset actually arrives. The tooling around this is where most home-grown approaches fall apart, because nothing reminds anyone that the sunset is coming.

• A consumer registry. You should know who depends on the taxonomy. Without that list, you can’t communicate changes. The dashboards, the AI training pipelines, the data quality rules, the regulatory reports — they all need to be on a list, and someone needs to be a contact for each.

The 2026 wrinkle

The new factor in the last eighteen months has been LLM-driven systems consuming taxonomies as part of their grounding context. This raises the cost of label and definition changes meaningfully. A subtly reworded scope note can change how an AI assistant classifies new records. A deprecated concept that wasn’t properly migrated can poison the model’s outputs in ways that are hard to attribute to the taxonomy change six months later.

The pattern emerging at teams that take this seriously is to treat the taxonomy version that the AI system is grounded against as a separately tracked thing — pinned, like a dependency in a software project — and explicitly upgrade it through a review process when the taxonomy changes. That sounds bureaucratic, and it is, but the alternative is a model that quietly drifts in semantics every time the steward fixes a typo.

The Friday board pack story is, on its own, a small embarrassment. Multiplied across an organisation’s analytical surface, the pattern of small embarrassments is what kills trust in a vocabulary program. The teams that get this right aren’t doing anything heroic. They’re just being precise about what changed, telling people, and treating their published vocabulary like a contract rather than a working document.