The ATS schema problem hiding inside skills based hiring data
Most employers say they want skills based hiring, yet their data still worships job titles and college degrees. When your Applicant Tracking System indexes only job, company, tenure and degree requirements, it cannot see the underlying capabilities or the core skills that actually drive performance. That is why skills based hiring data often looks impressive in a slide deck but fails inside the live hiring process.
Legacy ATS schemas were engineered for compliance and volume based recruitment, not for nuanced talent acquisition decisions grounded in structured skills assessments and work experience evidence. Résumés are parsed into job descriptions, dates, employers and college degree fields, while skills assessments, portfolio links and workplace innovation signals are treated as unstructured attachments. When roughly three quarters of your recruitment data is free text, you cannot run serious skills based analytics or compare candidates fairly across roles and companies.
Look at any mainstream ATS and you will see the same pattern repeated across thousands of hiring practices. The system can filter candidates by bachelor degree, previous job titles and companies, yet it cannot reliably answer which workers have intermediate Python skills or advanced financial modeling capabilities. That mismatch between what leaders say about future work and what the database can read about actual skills is the quiet failure mode of skills based hiring.
For senior HR leaders, this is not a technology curiosity, it is a governance and compliance risk. When your hiring process cannot show how skills assessments informed selection, you are exposed on fairness, DE&I metrics and level playing field claims. Regulators and courts will not care that your ATS vendor never modernized its schema, they will ask why your company’s skills data cannot prove that candidates were evaluated on job relevant skill rather than on proxies like college prestige. Recent guidance from regulators and industry bodies on algorithmic hiring and adverse impact analysis points in the same direction: you must be able to explain how human resources data, including skills based hiring data, shapes outcomes.
The same structural problem appears in internal mobility workflows that sit on top of the HRIS. Internal job postings are tagged by roles and departments, while internal mobility data about verified skills, certifications and project work experience lives in the Learning Management System or in performance reviews. Without a unifying skills based data layer, talent acquisition and internal mobility teams are effectively running two disconnected recruitment markets inside the same organisation.
Even sophisticated employers that run a global talent acquisition équipe often underestimate how much their hiring practices are constrained by the original ATS database design. They invest in better employer branding, more inclusive job descriptions and new sourcing channels, yet the underlying skills based hiring data model still treats skill as an optional text field. In one anonymised global technology firm, for example, an internal review found that less than 20% of requisitions initially included structured skills fields; after redesigning the schema and enforcing skills tagging, internal mobility moves in digital roles rose by more than 30% within a year. This is a single case study rather than a universal benchmark, but it illustrates how schema changes can unlock measurable gains. Until that kind of change becomes standard, companies will keep arguing about candidates in meetings using anecdotes instead of auditable skills assessments and evidence based recruitment metrics.
What a skills first data model really looks like
A genuine skills first architecture starts with a shared skills taxonomy, not with another sourcing campaign. Every job, from finance analyst to frontline service workers, must be expressed as a set of observable skills with proficiency levels, decay rates and accepted evidence sources. That is the only way to turn skills based hiring data from marketing language into operational infrastructure for recruitment and internal mobility.
In practice, this means mapping each role to 15 to 30 skills, each skill to clear behavioural indicators, and each indicator to specific assessments or work experience signals. A finance controller role, for example, might combine technical skills assessments in IFRS, scenario modeling and data literacy with behavioural evidence from past workplace innovation projects. When talent acquisition teams can read these mappings directly inside their tools, they can design skills based hiring practices that are consistent across locations and hiring managers.
Skills ontologies such as ESCO and O*NET give you a starting vocabulary, but they are not a plug and play solution. Their granularity often does not match your company’s skills reality, so you must decide where to merge, split or rename skills to reflect your own job architecture. The right move for a global bank will differ from a mid sized software company, and that is why a one size fits all ontology rarely levels the playing field for candidates.
Evidence is the second pillar of any serious skills based model. You need to define which assessments count, how long they remain valid, and how they interact with signals like college degree, non traditional college paths or on the job learning. A coding test taken three years ago should not carry the same weight as recent open source contributions, and a bachelor degree in finance should not automatically outrank proven workplace innovation in cross functional projects.
For global organisations, the challenge multiplies across markets and regulatory regimes. HR leaders who want to navigate the global talent space using human resources data need a governance framework that explains how skills based hiring data is created, validated and retired across countries. Research from firms such as Deloitte and Mercer on skills based organisations reinforces this point: skills taxonomies and skills assessments are now treated as core infrastructure, on par with payroll accuracy or FMLA leave tracking.
Once this model is in place, you can finally run meaningful survey work on hiring success, internal mobility outcomes and future work readiness. You can compare roles by the density of critical skills, track which recruitment channels yield candidates with the strongest verified skills, and test whether degree requirements are actually predictive of performance. At that point, talent acquisition stops being a black box and becomes a measurable system where each hiring process can be audited for fairness, efficiency and ROI.
Connecting skills data across ATS, LMS, performance and HRIS
Even the best skills taxonomy fails if it lives in a slide deck instead of in your production systems. The hard work begins when you try to connect skills based hiring data across ATS, LMS, performance management and the core HRIS without creating yet another silo. That integration problem is where most well intentioned skills based initiatives quietly stall.
Start with a brutally honest inventory of where skills data already exists in your organisation and how it is stored. In the ATS, you will find fragmented skills assessments, unstructured job descriptions and scattered notes about candidates that hiring managers rarely read twice. In the LMS, you will see course completions that may or may not reflect real skill, while in performance systems you will find manager ratings that mix potential, behaviour and technical competence.
The integration pattern that works in practice is to build a skills layer that sits above these transactional systems and synchronises only the fields that matter. That layer can be a dedicated skills intelligence platform, a data warehouse with a skills schema, or a graph database that links workers, roles, skills and evidence. A minimal schema for that layer might include fields such as worker_id (string), role_id (string), skill_id (string), proficiency_level (integer), evidence_type (enumeration), evidence_source_id (string), last_validated_at (timestamp) and confidence_score (decimal). What matters is that every job, every candidate and every internal employee can be represented as a vector of skills with timestamps and confidence scores.
Vendors are starting to move in this direction, but the market is fragmented and noisy. EdMyst and its SkillVector offering, for example, are often cited as an emerging skills intelligence ecosystem for data driven skills based hiring and internal mobility, while larger HRIS vendors are embedding skills graphs into their talent acquisition suites. These names are illustrative rather than exhaustive, and the specific capabilities vary by provider. You do not need to buy the most hyped product, yet you do need a clear view of how any new tool will exchange skills data with your existing HRIS, payroll and recruitment stack.
Integration is not just a technical API problem, it is also a workflow and governance issue. If recruiters cannot see skills assessments inside their hiring process screens, they will default back to scanning college degree fields and previous job titles. If managers cannot read internal mobility recommendations that highlight verified skills and work experience, they will keep posting external jobs that duplicate existing talent. A simple, actionable pattern is to define one canonical skills record per worker in the skills layer, update it whenever assessments or learning events occur, and then push summarised skills profiles back into the ATS, LMS and performance tools so that hiring managers and HR business partners see the same information.
Marketing teams have already learned this lesson in their own domain. They know that effective recruiting landing pages can turn visitors into qualified candidates only when the underlying data model can track which skills, messages and channels drive conversion. HR leaders should apply the same discipline to their own systems, treating skills based hiring data as a first class asset that connects sourcing, assessment, internal mobility and long term workforce planning.
The CPO decision: build a skills layer now or wait for vendors
Every Chief People Officer I speak with faces the same strategic fork in the road. Do you build a skills intelligence layer on top of your current stack now, or wait for your primary HRIS and ATS vendors to converge on a standard for skills based hiring data. Waiting feels safer, yet it quietly extends the life of degree requirements and job title proxies that no longer match the future work reality.
The case for acting now rests on both ROI and risk. Internal talent mobility programmes that use structured skills data consistently outperform peers on retention and engagement, which means every year of delay leaves money and talent on the table. When internal mobility is powered by transparent skills assessments and clear job descriptions, it also sends a strong signal to workers that the playing field is shifting from pedigree to capability.
On the risk side, regulators and courts are paying closer attention to how companies justify hiring decisions and promotion outcomes. If three quarters of your selection rationale still rests on college degree filters, unstructured interview notes and gut feel about cultural fit, you will struggle to defend your hiring practices. A skills based model, by contrast, can show how each candidate was evaluated on job relevant skill, which assessments were used, and how those assessments correlate with later success in the role.
Finance leaders are also starting to ask harder questions about the ROI of talent acquisition and recruitment technology. They want to read clear metrics that link skills based hiring to reduced time to fill, lower agency spend and better workplace innovation outcomes. Without a coherent skills data model, HR cannot credibly answer those questions, because the systems cannot connect hiring inputs to performance outputs at scale.
There is no universal blueprint, but there is a pragmatic sequence that works for most companies. First, define a minimum viable skills taxonomy for your top 50 roles, including both technical skills and behavioural capabilities that matter for success. Second, embed those skills into job descriptions, hiring process checklists and internal mobility workflows, so that candidates and managers see the same language from sourcing to promotion.
Third, choose one pilot area where you will treat skills based hiring data as a governed asset with clear ownership, data lineage and audit trails. That pilot might be digital roles, finance functions or a critical operations segment where skills based recruitment failures are expensive. From there, you can expand the skills layer across the organisation, always remembering that the goal is not dashboards, but defensible decisions.
Key figures on skills based hiring data and internal mobility
- More than half of employers have begun moving to skills based models, with nearly a quarter planning to follow within the next planning cycle, according to survey work by AIHR and similar research providers, which shows that skills based hiring data is rapidly becoming a mainstream expectation rather than an experimental practice.
- Internal talent mobility programmes that leverage structured skills data outperform peers on retention and engagement metrics, as reported by Mercer and other human capital analysts, highlighting that investments in skills based architectures pay off beyond the hiring process itself.
- Advanced organisations that invest in dynamic skills inventories and internal talent marketplaces report stronger readiness for future work transitions, because they can redeploy workers across roles based on verified skills assessments instead of static job histories.
- Vendors such as EdMyst, with its SkillVector skills intelligence ecosystem, are frequently referenced as examples of how the market is shifting from resume centric tools toward platforms that treat skills based hiring data as the core object connecting candidates, employees and jobs.
- As a simple, appendix style illustration, a minimal JSON representation of a skills record might look like this: {"worker_id":"12345","role_id":"FIN-ANALYST","skills":[{"skill_id":"IFRS","proficiency_level":3,"evidence_type":"assessment","evidence_source_id":"test-987","last_validated_at":"2025-01-15T10:00:00Z","confidence_score":0.86}]}, which can then be written into a SQL table and synchronised between ATS, LMS and HRIS via scheduled integrations.
