Taxonomy, ontology, and why a skills list is not a skills model

Everyone starts with a list. Almost no one gets past it.

Ask an organisation how it's becoming skills-based and, nine times out of ten, the answer starts with a taxonomy: a big, tidy list of skill names, often bought or scraped, sometimes arranged into a tree. This is a reasonable first step. It gives everyone the same words. But a list of words is not a model of skill — and the gap between the two is exactly where most skills programmes quietly stall.

The distinction that matters is between a taxonomy and an ontology. A taxonomy names things. An ontology says what they mean — how they relate, what "good" looks like, and what it takes to prove one. You can tag with a taxonomy. You can only measure with an ontology.

What a taxonomy is — and where it stops

A skills taxonomy is a controlled vocabulary. At its best it's hierarchical, deduplicated and shared, so "communication," "communication skills" and "verbal communication" don't fragment into three unrelated tags. Ours begins from a large global taxonomy — roughly 33,000 skills, industry-scoped, that an organisation can fork and extend for its own context.

That's genuinely useful. It's also where a taxonomy runs out of road. A list of names cannot tell you what proficiency in a skill actually looks like, how one skill relates to another, which skills a role requires, or what evidence would prove someone has it. It gives you the nouns. It gives you none of the grammar.

What an ontology adds: structure, levels, relationships, evidence

An ontology is the vocabulary plus the semantics — the rules and relationships that make the words mean something. In our system it has four load-bearing parts, layered on top of the taxonomy.

1. A hierarchy, not a flat list

Skills don't float. They roll up: behaviours → skills → competencies → competency groups. "Acknowledged the objection and reframed to value" is a behaviour; it evidences the objection-handling skill; that skill sits under a commercial competency; competencies group into coarse buckets like execution or governance. This roll-up is what lets a hundred small observations become one defensible statement about capability.

2. Proficiency scales — what "good" means, in context

A skill without a level is a coin toss. The ontology defines proficiency scales — explicit level descriptions (novice to expert, a 1–5 band, CEFR for language, binary for pass/fail compliance). Crucially, the scale is context-aware: what counts as level 5 in one industry is not the same as another. A rubric is attached to each level, so a score is a position on a defined ladder, not a naked percentage.

3. Anchors — what a role actually requires

Measurement needs a target. An anchor (a role, or a course) binds a set of skills to the levels that role requires. Now "good enough" has a definition: the role needs objection-handling at level 3, and this person is measured at level 3 with high confidence. The requirement and the measurement speak the same language because both are expressed in the ontology.

4. Skill proof — evidence bound to the level

Finally, the ontology says what a claim is made of. A skill proof is not a name and not a number — it's a measured level, tied to the specific evidence that earned it, carrying a stated confidence. The evidence maps back to behaviours; the behaviours map to the skill; the skill maps to the competency and the role. Every claim is inspectable all the way down.

Why the same skill isn't the same skill everywhere

The strongest argument for an ontology over a taxonomy is context. The same skill name can mean opposite things in different settings. A software seller who pushes hard to expand a deal is demonstrating strong commercial skill. A pharmaceutical medical liaison who does the same has committed a compliance breach — they're not allowed to promote off-label. "Assertive selling" as a flat tag treats these identically, which is worse than useless.

A taxonomy can hold the word. Only an ontology can hold the meaning — the per-context proficiency scale and rubric that make the same behaviour excellent in one place and a violation in another.

Why the result is a graph, not a spreadsheet

Once skills roll up to competencies, anchors require skills at levels, and proofs bind evidence to behaviours, the whole thing stops being a list and becomes a network of relationships. That's why we call it a skills graph, not a skills database. And a graph is queryable in ways a list never is: who can already do what this role needs? Where is capability thin across a team? Who is one skill away from the next seat? Those questions are answerable only because the ontology encoded the relationships in the first place.

Where measurement comes in

All of this exists to make one thing possible: measurement you can trust. A score only means something when it lands on a defined scale, rolls up through a known hierarchy, points back to real evidence, and answers a role's actual requirement. That is the entire job of the ontology — and it's the foundation the next generation of skills measurement, including reading skill from real work, is built on. Get the model right, and the measurement has somewhere to land. Skip it, and every score is a number without a denominator.