Skills Taxonomy Frameworks: O*NET, ESCO, and the Skills-Based Hiring Stack

Skills taxonomies are the structured vocabularies that underlie skills-based hiring practices. The two dominant taxonomies — O*NET (US Department of Labor) and ESCO (European Commission) — provide the public-domain skill classifications that vendor and in-house systems map to. This article walks through what these taxonomies cover and how they integrate with skills-based hiring practice.

Data Notice: Taxonomy frameworks evolve over time. The descriptions here reflect O*NET and ESCO at time of writing; consult current documentation for updated classifications.

What skills taxonomies actually do

Three functions:

• Vocabulary standardization. Mapping the free-text skill claims candidates and employers use (“Python”, “data analysis”, “leadership”) to canonical terms with stable definitions.
• Hierarchy and relationships. Skills relate to other skills (parent-child, related-to, prerequisite-for). Taxonomies encode these relationships.
• Cross-system interoperability. Different systems (ATS, assessment platforms, learning systems) using the same taxonomy can exchange skill information without per-system mapping work.

The functions interact: standardized vocabulary enables interoperability; relationship encoding enables intelligent matching beyond exact-string-match.

O*NET overview

O*NET is the US Department of Labor’s occupational information network, providing detailed job-and-skill classifications for the US labor market:

• Occupation classification. SOC (Standard Occupational Classification) codes that map roles to standardized categories. Used in BLS Occupational Outlook reports and most US labor-market research.
• Skill descriptors. Each occupation has documented knowledge, skill, ability, and task requirements.
• Update cadence. O*NET data is updated through ongoing surveys; the data is refreshed regularly but not continuously.

ONET is the dominant taxonomy for US-focused systems. AIEH role pages use ONET SOC codes (15-1252 for Software Developers, 15-1255 for Web/Digital Interface Designers, 15-1212 for Information Security Analysts, etc.) for external-classification mapping.

ESCO overview

ESCO is the European Skills, Competences, Qualifications and Occupations classification, providing the EU-equivalent function:

• Multi-language coverage. ESCO supports all 24 EU official languages plus additional languages, enabling cross-border labor-market interoperability.
• Skill-occupation linking. Skills are linked to occupations bidirectionally, enabling occupation-to- skill and skill-to-occupation queries.
• Open data with regular updates. ESCO is published as open data with periodic version updates.

ESCO is the dominant taxonomy for European-focused systems and increasingly used internationally as a reference.

How vendor and in-house systems use taxonomies

Three patterns:

• Direct adoption. Some systems use ONET or ESCO IDs directly without modification. The pattern is rare in practice because the public taxonomies don’t always match the granularity employers need — ONET classifies software-engineering at the SOC 15-1252 level, but modern hiring distinguishes Frontend, Backend, Full-Stack, Mobile, Security, ML, Data, and other specialties at finer granularity than the SOC code captures. Direct adoption works for high-level workforce reporting; less well for specific hiring decisions.
• Mapped extension. Systems use proprietary taxonomies that map to O*NET or ESCO at the canonical- category level while extending granularity for specific use cases. Most modern HR-tech vendors use this pattern: vendor’s internal taxonomy maps “Senior React Developer” to ESCO’s relevant software-engineering category for cross-system interoperability while preserving the granularity that makes vendor-internal matching useful. The mapped-extension approach balances interoperability with practical granularity.
• Custom taxonomy with no mapping. Older or more-isolated systems use entirely custom taxonomies without external mapping. Produces interoperability problems that compound over time — data exchange with other systems requires per-system translation work; vendor changes require taxonomy migration; multi-system reporting requires reconciliation. The pattern persists at organizations with substantial HR-system investment that predates standardized taxonomies, but greenfield systems should avoid it.

Practitioner workflow: how to choose a taxonomy approach

Three practical questions for organizations selecting a skills-taxonomy approach:

• What’s the cross-system interoperability requirement? Organizations exchanging skill data with multiple systems (ATS + LMS + HRIS + assessment platforms) benefit from canonical-mapped taxonomies that reduce per-pair-of-systems translation work. Organizations with isolated systems may not need the interoperability-cost overhead.
• What’s the granularity requirement? Hiring decisions often need finer granularity than O*NET or ESCO provide directly; reporting and workforce-analysis decisions often work at the canonical-category level. The right granularity depends on what decisions the taxonomy supports.
• What’s the maintenance commitment? Taxonomies evolve as skills evolve; custom taxonomies require ongoing maintenance that organizations sometimes underestimate. Mapped-extension approaches inherit some maintenance from the canonical taxonomy (O*NET / ESCO updates) and add maintenance only for the extensions.

How AI-driven skills extraction interacts with taxonomies

Modern AI-driven skill-extraction tools (parsing resumes, job descriptions, performance reviews into skill claims) produce free-text skill phrases that need taxonomy mapping to be useful for downstream systems. The mapping problem is non-trivial:

• Synonym handling. “Python”, “Python programming”, “Python development”, “Pythonic coding” all refer to the same skill but require canonical mapping to a single taxonomy entry.
• Skill specificity vs general claim. “Software engineering” vs “backend Python with Django and PostgreSQL” represent different specificity levels; taxonomy systems need to handle the specificity hierarchy.
• Emerging skills. New technologies and frameworks appear faster than canonical taxonomies update; AI-extraction tools surface these before taxonomies catch up. Mapped-extension approaches accommodate this by extending the taxonomy without waiting for canonical updates.

The combination of AI-driven extraction and well-designed taxonomy systems produces skills-data infrastructure that supports modern hiring practices substantially better than free-text skill claims alone.

How AIEH integrates skills taxonomies

AIEH role pages document ONET SOC codes and ESCO codes in the frontmatter for cross-system interoperability. Each role page’s onet_code and esco_code frontmatter fields map the role to the canonical-taxonomy categories — for example, the Frontend Engineer role page references SOC 15-1255 (Web and Digital Interface Designers, the 2018 SOC revision specifically introduced for digital interface design work). The scoring methodology uses internal skill-name conventions that map to ESCO and ONET at the canonical- category level while extending granularity for AIEH-specific assessment categories. The mapped-extension pattern enables AIEH credentials to interoperate with vendor systems (applicant tracking, HR information systems, learning management) that use canonical taxonomies, while preserving the granularity that makes AIEH’s role-bundle calibration meaningful.

Common pitfalls

Five patterns recurring at organizations attempting skills-taxonomy adoption:

• Treating skills as flat lists. Skills have relationships — parent-child (programming → Python), prerequisite-for (linear algebra → ML), related-to (React ↔ Vue, both frontend frameworks). Matching algorithms that ignore relationships miss matches that hierarchy-aware matching catches; flat-list approaches produce false negatives where canonical-mapped approaches succeed.
• Skipping international compatibility. Multi- national employers face taxonomy-fragmentation problems if internal systems use US-only or EU-only taxonomies without cross-mapping. The fragmentation surfaces when operations expand internationally and the existing taxonomy doesn’t transfer cleanly. Strong organizations choose mapped-extension approaches that bridge O*NET and ESCO from the start.
• Treating taxonomies as static. Skills evolve as technologies and frameworks emerge or deprecate; taxonomies that don’t update produce mismatched data. Organizations that adopt a taxonomy and never review it find their skill data becomes increasingly stale over years, undermining the value the taxonomy was supposed to provide.
• Over-engineering taxonomy granularity. Some organizations build taxonomies with thousands of skill entries, more granular than the matching algorithms need. Excessive granularity produces maintenance burden without proportional value; the matching often performs better at moderate granularity (hundreds rather than thousands of skill entries).
• Inconsistent application across systems. Even when an organization adopts a canonical taxonomy, individual systems often use it inconsistently — some use the IDs, others use free-text that gets mapped inconsistently. The discipline of consistent application matters as much as the taxonomy choice itself.

Takeaway

Skills taxonomies provide the structured vocabulary that underlies skills-based hiring practice. ONET (US) and ESCO (EU) are the dominant public-domain options; modern HR-tech vendors typically use proprietary extensions mapped to these canonical frameworks. The mapped-extension pattern balances interoperability with practical granularity. AIEH integrates ONET SOC codes and ESCO codes in role-page frontmatter for cross-system interoperability while extending granularity where role-specific signal warrants it.

The right taxonomy approach depends on organizational scale, international footprint, and matching-precision requirements. Larger and more-international organizations benefit substantially from canonical-mapped approaches; smaller single-system organizations may not need the interoperability overhead.

Takeaway

Skills taxonomies provide the structured vocabulary that underlies skills-based hiring practice. ONET (US) and ESCO (EU) are the dominant public-domain options; modern HR-tech vendors typically use proprietary extensions mapped to these canonical frameworks. AIEH integrates ONET and ESCO codes in role-page frontmatter for cross-system interoperability.

For broader treatments of skills-based hiring practices and how taxonomies fit into the broader hiring loop, see skills-based hiring evidence, skills vs credentials, ai in recruiting evidence for the interaction with AI-driven skill-extraction tooling, and the scoring methodology for the AIEH calibrated- credential approach to taxonomy integration.

---

Sources

• US Department of Labor. (2024). ONET Online.* https://www.onetonline.org/
• European Commission. (2024). ESCO — European Skills, Competences, Qualifications and Occupations. https://esco.ec.europa.eu/en
• Burning Glass Institute / Lightcast. (2022). The Emerging Degree Reset. https://www.burningglassinstitute.org/research
• Sackett, P. R., & Lievens, F. (2008). Personnel selection. Annual Review of Psychology, 59, 419–450.
• US Bureau of Labor Statistics. (2024). Occupational Outlook Handbook. https://www.bls.gov/ooh/