Skills ontology
A structured framework that organizes skills, competencies, and job functions into a hierarchy so AI systems and hiring teams can match candidates across different titles and terminology.
Michal Juhas · Last reviewed June 21, 2026
What is a skills ontology?
A skills ontology is a structured map of relationships between skills, job titles, and competencies. It defines that "Python developer" and "Python engineer" refer to the same underlying capability, that "machine learning" is a parent node for "NLP" and "computer vision," and that a "growth marketer" likely overlaps with certain data analysis and performance marketing skills.
In hiring, ontologies do the translation work that humans do automatically but AI tools cannot do without explicit structure. A recruiter reading "full-stack JS" and "Node + React" knows they mean overlapping skills. A resume parser treating them as different strings will miss the match. The ontology closes that gap.
In practice
- A TA team at a 500-person fintech maps its job architecture to Lightcast's open skills taxonomy, then adds 40 custom nodes for proprietary regulatory and product skills. Their ATS now surfaces qualified candidates across four different job title variations for the same role family.
- A sourcer building a Boolean string for a DevOps engineer starts from the ontology to find canonical synonyms: infrastructure engineer, site reliability engineer, platform engineer. Three strings become one, and coverage improves.
- A TA ops lead audits their vendor ontology after noticing the screener was systematically missing candidates from German-speaking markets who listed skills in German. The vendor taxonomy had incomplete German-language skill nodes. She adds a custom mapping layer.
Quick read, then how hiring teams use it
This is for TA ops leads, sourcers, and recruiting technologists who configure ATS matching, AI screening, or skills-based hiring tools. Skim the first section for shared vocabulary. Use the second section when you are building or auditing a taxonomy setup.
Plain-language summary
- What it means for you: A skills ontology is the shared vocabulary your AI tools need to stop treating synonyms as different skills and missing qualified candidates.
- How you would use it: Wire your job descriptions, ATS, and sourcing tools to the same ontology so skill matching is consistent across the stack.
- How to get started: Audit your last 50 job descriptions for inconsistent skill terminology. Map the variation to a vendor taxonomy and flag the gaps. That gap list is your custom ontology backlog.
- When it is a good time: Before deploying any AI screening tool, when consolidating ATS data after a merger, and when hit rate on requisitions keeps dropping despite unchanged job requirements.
When you are running live reqs and tools
- What it means for you: At scale, an inconsistent taxonomy means your AI screener scores the same candidate differently depending on how they described their skills. Fixing this at the ontology layer is cheaper than tuning individual req screeners.
- When it is a good time: During ATS selection, when onboarding a new AI screening or matching tool, and when sourcing pass-through rates vary unexpectedly by role family.
- How to use it: Export candidate skill tags from your ATS for a 90-day window. Run a frequency and clustering check. Identify synonyms landing in different nodes. Submit corrections to your vendor or update your custom mapping layer.
- How to get started: Start with the highest-volume role families and work outward. Most ontology problems concentrate in 20 percent of skill nodes that cover 80 percent of your sourcing activity. See skills-based hiring and skills gap analysis for adjacent tooling.
- What to watch for: Ontologies that have not been updated in 12 months are actively misleading in fast-moving domains like AI engineering, cloud infrastructure, and data science. Subscribe to your vendor's changelog and treat stale nodes as a data quality risk.
Where we talk about this
On AI with Michal sessions, skills ontologies come up when teams are configuring AI screening tools or building sourcing workflows that need to handle inconsistent candidate terminology. If you want to map your own job architecture to a canonical taxonomy and test it against live data, bring your role families to an AI in recruiting workshop.
Around the web (opinions and rabbit holes)
Third-party creators move fast. Treat these as starting points, not endorsements, and do not copy stranger scripts that move candidate data.
YouTube
- Search "skills taxonomy for HR technology" on YouTube for vendor-produced explainers from Lightcast, Workday, and SAP SuccessFactors on how their ontologies are structured and maintained.
- "Skills-based organization" talks from Deloitte and McKinsey on YouTube cover why large enterprises are rebuilding job architectures around skills nodes rather than titles.
- r/recruiting threads on "ATS skills matching" surface practitioner complaints about false negatives in vendor taxonomies that are useful for auditing your own setup.
- r/humanresources discussions on "skills-based hiring" include implementation experiences from TA teams who have tried to operationalise ontology-driven screening.
Quora
- What is a skills ontology in HR technology? collects answers from practitioners and vendors explaining the concept and the main use cases.
Related on this site
- Glossary: Skills-based hiring, Skills gap analysis in recruiting, AI bias audit, Adverse impact, Embeddings in recruiting, JD generation with AI, EU AI Act and hiring
- Blog: AI sourcing tools for recruiters
- Live cohort: AI in recruiting workshop
- Course: Starting with AI: the foundations in recruiting
- Membership: Become a member
Frequently asked questions
What is a skills ontology and why do recruiting teams care?
A skills ontology is a structured vocabulary that maps relationships between skills, competencies, job titles, and related concepts. It defines that a "Node.js developer" and "backend JavaScript engineer" share the same underlying skills, so an ATS or AI screener can match candidates across inconsistent job title terminology. Recruiting teams care because sourcing tools, resume parsers, and job description generators all need a common language to work accurately. Without one, AI tools return gaps or duplicates where humans would see obvious matches. Vendors like Lightcast, EMSI, and Workday Skills Cloud publish ontologies; some companies build proprietary ones mapped to their internal job architecture. See skills-based hiring for why ontologies underpin competency-driven hiring.
How does a skills ontology improve AI-driven candidate matching?
AI matching models need a consistent representation of skills to compare a candidate profile against a job requirement. Without an ontology, a model trained on raw resume text sees "React" and "ReactJS" as potentially different tokens, or misses the link between "machine learning" and "ML engineer." An ontology acts as a normalisation layer: it maps surface-level variation to canonical nodes so the model scores on meaning, not string similarity. In practice this improves recall (finding qualified candidates you would otherwise miss) and reduces noise from title inflation. Teams using embeddings-based search layer the ontology on top of vector representations to constrain the semantic space. See embeddings in recruiting for how the underlying vectors work.
What are the risks of using a vendor ontology off the shelf?
Vendor ontologies reflect the jobs and skills visible in their training data, which is usually weighted toward large US or UK employers. If your hiring covers niche markets, emerging technical specialisations, or non-English-speaking regions, the vendor ontology may map your roles poorly or omit key skill nodes entirely. A second risk is proprietary lock-in: if your matching and screening logic depends on a vendor taxonomy, migrating to a different ATS or sourcing tool becomes expensive. Third, ontologies age: skills emerge and deprecate faster than most vendors update their taxonomies. Teams doing high-volume technical hiring should audit vendor ontology coverage quarterly and maintain a supplementary custom taxonomy for fast-moving domains. See AI bias audit for how ontology gaps can produce disparate screening outcomes.
How do teams build or adopt a skills ontology in practice?
Most teams start with a vendor ontology (Lightcast, EMSI, Workday Skills Cloud) as a foundation, then layer in custom nodes for proprietary terminology, internal job architecture, and niche skill areas the vendor taxonomy undercoveres. The process involves: exporting your last 12 months of job descriptions and resume text, running frequency analysis on skill terms, mapping them to the closest vendor node, and flagging unmapped terms for custom addition. IT and data teams usually own the technical pipeline; TA owns the skill definitions. Maintenance cadence matters: set a quarterly review to add emerging skills (new AI frameworks, new regulatory domains) and retire deprecated ones. Connect the ontology to your JD generation tool and ATS so new requisitions automatically use canonical terminology. See JD generation with AI for where ontology anchors job description quality.
Where does a skills ontology intersect with GDPR and bias risk?
Skills ontologies touch GDPR when they are used to automatically classify and score candidates at scale. Under GDPR Article 22, automated decisions that significantly affect a data subject require transparency and, in some cases, human review. If your ontology-powered screener filters candidates out before a recruiter sees them, you need to document what the taxonomy maps, how classification errors are caught, and how candidates can challenge a decision. Bias risk emerges when the ontology encodes historical hiring patterns: if certain skill synonyms were used more by one demographic group and the ontology maps them differently, the screener may produce disparate impact. Audit ontology-based screening output by demographic cohort at least annually. See EU AI Act and hiring and adverse impact for the regulatory framing.