ArchitecturePeople & Organizational Performance

How to build a skills taxonomy that workforce planning can actually use

A skills taxonomy is the data model behind skills-based workforce planning: the list of skills, how proficiency is described, how skills attach to roles and people, and what evidence supports each link. This page sets out the layers of a working architecture, when to adopt ESCO, O*NET or SFIA instead of building, how to use language models to infer skills without losing accuracy, and the governance that keeps the model current.

Reviewed 7 min read

On this page
  1. Taxonomy, ontology and framework: what each one is for
  2. Adopt, adapt or build: ESCO, O*NET and SFIA compared
  3. Five layers of a working skills architecture
  4. The core data model: skills, evidence and confidence
  5. Inferring skills with language models while people stay in the loop
  6. Where the taxonomy connects to HR, learning and planning systems
  7. Governance rules that keep a skills taxonomy current
  8. Privacy, fairness and trust risks in inferred skills
  9. Questions and answers
  10. Sources

Taxonomy, ontology and framework: what each one is for

The terms are often used interchangeably, which turns design discussions into vocabulary disputes. Agree the definitions first.

Skills taxonomy
A controlled, usually hierarchical list of skills with stable identifiers, grouped into clusters. It answers the question 'what do we call this skill, and where does it sit?'
Skills ontology
A taxonomy plus typed relationships: one skill relates to another, is a prerequisite for a third, or commonly appears in a given role. It supports inference and recommendations at the cost of more upkeep. Our wiki explains ontologies in general.
Competency framework
A set of behavioral expectations, often for leadership or values, described at several levels. Useful in development conversations, but too broad on its own for staffing or workforce planning.
Proficiency scale
A short ordered scale, each level described by observable behavior, used to say how well someone applies a skill.
Role profile
The skills a role requires, each at a target proficiency and marked as essential or useful.

Adopt, adapt or build: ESCO, O*NET and SFIA compared

CriterionESCOO*NETSFIABuild your own
Maintained byThe European Commission's employment directorate-general1A program sponsored by the US Department of Labor's Employment and Training Administration2The SFIA Foundation, a not-for-profit body3Your organization, for as long as you use it
CoverageOccupations, skills and competences, and qualifications across the economy1US occupations, described through tasks, work activities, skills and knowledge2Professional skills for building, running and securing technology and data3Exactly the areas you choose to model
StructureA multilingual classification linking occupations to skills and competences1Task statements linked to detailed and generalized work activities2Skills described against seven levels of responsibility3Whatever hierarchy you design and can keep consistent
Access and costFree to consult online, download or use through an API1Publicly funded and openly published by the O*NET Resource Center2Free for most non-commercial use; large organizations and commercial users pay a license fee3Internal effort for design, validation and upkeep
Best fitEU employers needing cross-border, multilingual consistencyUS employers and task-level work analysisTechnology, data and digital rolesNarrow proprietary skills no public framework covers

Many organizations combine them: a public framework for the broad base, SFIA for technology roles and a thin internal layer for proprietary skills, each mapped to one internal identifier.

Five layers of a working skills architecture

Uses01Integration02Inference03Core data model04Reference frameworks05
  1. Uses

    Workforce planning, internal mobility, learning investment and AI task analysis consume the model.

  2. Integration

    The HR system of record, learning platform and talent marketplace read and write through one interface.

  3. Inference

    Language models propose skills from job descriptions, learning records and project data, with confidence scores.

  4. Core data model

    Skills, clusters, proficiency levels, role profiles and the evidence linking people to skills.

  5. Reference frameworks

    ESCO, O*NET or SFIA identifiers, plus a thin layer of internal skills.

Conceptual layering of a skills architecture: each layer depends on the one beneath it. It does not depict any specific product.

The core data model: skills, evidence and confidence

The smallest useful model has five entities. A skill has a stable identifier, a name, a definition and a mapping to the reference framework it came from. A cluster groups related skills for navigation and reporting. A proficiency scale defines a handful of levels, each anchored in observable behavior rather than adjectives. A role profile lists required skills at target levels. An evidence record links a person to a skill at a level, with its source and date.

Evidence is where most taxonomies fall short. A self-declared skill, a manager's validation, an assessment result, a completed project and an inference from a CV are not equally reliable, and the model should say which one supports each link. Store the source type, a confidence value and a review date, so planners can filter to validated skills when a decision matters and accept inferred ones when they are only exploring.

Keep the number of proficiency levels small. Fine-grained scales look precise but produce inconsistent ratings, because managers cannot reliably tell adjacent levels apart.

Inferring skills with language models while people stay in the loop

  1. Map to identifiers, not free text

    Ask the model to choose from the taxonomy's existing skills and return their identifiers. Free-text output multiplies synonyms and breaks reporting.

  2. Keep the source and a confidence score

    Store the passage of the job description or learning record that supports each suggestion, so reviewers can check it at a glance.

  3. Route uncertain suggestions to review

    Send low-confidence suggestions to a skills steward or line manager, and auto-accept nothing that will feed a decision about an individual.

  4. Let employees confirm or correct

    Show people the skills inferred about them and let them accept, reject or adjust each one. Their corrections are also the best training signal you will get.

  5. Watch for drift and gaps

    Track which suggestions reviewers reject and which skills keep appearing in text without a taxonomy match; both point to changes the prompts or the taxonomy need.

Where the taxonomy connects to HR, learning and planning systems

Treat the taxonomy as a shared reference service rather than a table inside one application. The HR system of record holds people and positions; the learning platform tags content and completions with skill identifiers; the talent marketplace matches people to projects and roles; workforce-planning models add up supply and demand by skill. If each system keeps its own skill list, the organization spends its effort reconciling lists instead of planning. One source with published identifiers and a change feed lets every consumer stay in step.

The same identifiers should flow into downstream analysis. A task-level AI impact assessment, for instance, is far easier to turn into reskilling pathways when the skills each new task needs already exist in the taxonomy.

Governance rules that keep a skills taxonomy current

0 of 6 checked

Privacy, fairness and trust risks in inferred skills

Inferred skills used in decisions about individuals

Early signalSkill scores feed promotion, task allocation or performance reviews.

MitigationTreat such uses as potentially high-risk under Annex III of the EU AI Act4, keep human review, and limit unvalidated inferences to exploratory planning.

Employees cannot see or correct their profiles

Early signalPeople learn about inferred skills only when a recommendation surprises them.

MitigationExplain what is inferred and from which sources, and offer a way to correct it; under the GDPR, people have rights to information about processing and to rectification of inaccurate data5.

Historical bias copied into the model

Early signalSome skills appear far more often for some groups because of who historically received which projects or titles.

MitigationCompare suggestion rates across groups, and weight assessed evidence above inferences drawn from job titles.

Skill sprawl

Early signalThousands of near-synonyms, and nobody can find the skill they mean.

MitigationEnforce the adding criteria, merge synonyms in each release and stop at the granularity decisions actually use.

Questions and answers

How granular should the skills in a taxonomy be?

As granular as the decisions that use it, and no more. A useful test is whether two people holding different versions of a skill would be staffed differently: if not, they are one skill. Workforce planning usually works at cluster level, while staffing and learning work at skill level. Specific tools and products are often better stored as attributes of a skill than as skills in their own right.

How many skills is too many?

There is no fixed number; the signal is behavior. If people cannot find the skill they mean, if stewards keep merging duplicates, or if most skills have no evidence attached to anyone, the taxonomy has grown beyond what you can maintain. Pruning skills that no role profile or decision uses is usually the quickest fix.

How do we keep a skills taxonomy current without a large central team?

Distribute stewardship by domain, so engineers look after engineering skills and finance looks after finance skills, with a small central owner who runs the release process. Use rejected inferences and unmatched skill mentions as a standing backlog. Most upkeep then happens as part of normal work instead of in occasional overhauls.

Should employees see the skills the system infers about them?

Yes. Showing people their inferred skills and letting them correct them improves accuracy, builds trust and supports transparency duties under data protection law. Keep the difference visible: a skill the person confirmed or a manager validated should look different from one a model suggested, and planners should be able to filter on that difference.

Sources

  1. What is ESCO (European Skills, Competences, Qualifications and Occupations) — European Commission · checked 10 October 2026
  2. O*NET Resource Center: overview of the O*NET program and content model — National Center for O*NET Development, sponsored by the US Department of Labor · checked 10 October 2026
  3. About SFIA, the Skills Framework for the Information Age — SFIA Foundation · checked 10 October 2026
  4. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Annex III — EUR-Lex · checked 10 October 2026
  5. Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex · checked 10 October 2026

More in People & Organizational Performance

Back to People & Organizational Performance

Next step

Review your skills data model before you buy a skills platform

Describe where skills data lives today and which decisions it should support. We will suggest whether to adopt, adapt or build, and what governance to set up before the first release.

Discuss a skills taxonomy