A skills taxonomy is a controlled vocabulary: a fixed list of skill labels, each with a stable identifier and defined relationships to occupations and other skills. It standardises what a skill is called. It does not record how well a person performs it, when that was last checked, or what evidence sits behind the claim. Those are separate fields, and you have to add them yourself.
That distinction is the whole problem with most skills data. Organisations spend a year choosing a taxonomy, map every role to it, and end up with a database of rows that read "Priya — SQL" — a label attached to a name, with no level, no date, no source. It is tidy. It is also unusable by anyone outside the team that built it, and only marginally useful inside it.
Here is what the public taxonomies actually give you, and the seven steps that turn a naming convention into skills data another system can read.
What each public taxonomy carries — and what it leaves out
ESCO — European Commission
- ESCO describes 3,039 occupations and 13,939 skills, translated into 28 languages; current release v1.2.1, last updated December 2025.
- Free, open, multilingual and linked to occupations — the strongest option for cross-border work.
- Carries no person-level proficiency scale. A skill is present or absent in an occupation profile.
O*NET — U.S. Department of Labor
- O*NET holds over 900 occupation profiles covering more than 55,000 jobs, built on a Content Model of 277 descriptors across six domains.
- It does carry numeric ratings — but they describe what the occupation requires, not what a named individual can do. Reading an O*NET level rating as a candidate's score is a category error.
Lightcast Open Skills
- Open Skills holds 34,000+ skills extracted from hundreds of millions of job postings and profiles.
- Best market currency of the four: new tool and technology names appear here first. Still a label, not a level.
SFIA 9 — released October 2024
- SFIA defines skills at specific points on seven levels of responsibility, so proficiency is built into the structure rather than bolted on.
- Narrow by design — digital and technology professions — but the level architecture is the one worth copying.
National frameworks sit alongside these. India's revised NSQF, notified in 2023, runs eight levels described across five domains including professional knowledge, technical skill and level of responsibility. That is a statement about a qualification, not about how a particular holder performed last Tuesday.
Step 1 — Pick a spine, and pick it for a reason
Choose one taxonomy as the system of record and treat everything else as a translation. The reason should be about who reads your data: ESCO if you hire or place people across borders, Lightcast if you need emerging tool names in weeks rather than release cycles, SFIA if your population is technical and you want levels out of the box, your national framework if regulators or funding bodies consume the output.
Pick badly and you can remap later. Pick two spines and you will spend the next three years reconciling them.
Step 2 — Cut the list to skills that carry decisions
A taxonomy with 13,939 entries is a reference, not a plan. For any given role, the skills that change a hiring, promotion or deployment decision are usually between eight and twenty. Everything else is context you can look up when you need it.
The test for inclusion: would a genuinely different decision follow from a high score versus a low one? If not, the skill belongs in the job description, not in the measured set.
Step 3 — Attach a proficiency scale the taxonomy doesn't supply
Three to five levels, each with behavioural anchors describing observable work, not adjectives. "Advanced" means nothing across two teams. "Can design a normalised schema for a new subject area and justify the trade-offs to an engineer who did not attend the design session" means something to both.
SFIA's structure is instructive here: its levels describe autonomy, influence, complexity and business skills, so the same level means roughly the same thing across unrelated skills.
Step 4 — Record the evidence type, not just the number
Every skill claim should carry the method that produced it. The spread in quality is large: the classic meta-analysis of self-evaluations of ability found a mean correlation of roughly .29 with measured performance (Mabe and West, 1982, Journal of Applied Psychology). A self-rated 4 out of 5 and a work-sample-scored 4 out of 5 are not the same fact and should never share a column.
Use a short, closed list — self-rated, manager-rated, course completion, proctored assessment, scored work sample, certified third-party — and make it mandatory. The Standards for Educational and Psychological Testing are clear that validity attaches to a specific interpretation for a specific use, which means the interpretation has to be recorded alongside the score.
Step 5 — Date every claim and record the conditions
Two fields, both cheap, both routinely omitted: when the evidence was generated, and under what conditions. Conditions means supervision and integrity context — whether the assessment was proctored, whether behavioural signals flagged anything. AssessAll returns an integrity band with each AI-proctored result precisely so that this travels with the score rather than living in a separate audit log.
A three-year-old unsupervised self-rating and a last-month proctored scenario score can both read "Level 3". Only the date and conditions fields tell a downstream reader which one to trust.
Step 6 — Store identifiers, not labels
Store the taxonomy's URI or concept code as the primary key and treat the human-readable label as display text. Labels get renamed between releases; SFIA 9 alone renamed ten skills and restructured five. Systems keyed on strings quietly break. Systems keyed on identifiers survive the upgrade.
This is also what makes a skill record portable. The Rich Skill Descriptor work now hosted by Credential Engine exists for exactly this reason: its CTDL vocabulary supports 66 metadata types for describing a single skill, and the public Credential Registry already holds more than 51,000 open skills from hundreds of sources. A Skill Passport is only portable if what it points at has an address.
Step 7 — Crosswalk deliberately, and expect loss
Mapping between taxonomies is normal and lossy. The official ESCO–O*NET crosswalk was built with transformer models plus human validation by both the ESCO team and U.S. Department of Labor experts; the best model returned the correct ESCO occupation as its first suggestion 85% of the time, rising to 90% when narrow, broad and close matches are allowed. A second version adds "related" matches, which the Commission itself flags as lower-quality data that did not go through the same quality assurance.
That is the ceiling on a carefully built, publicly funded, expert-reviewed crosswalk between two mature classifications. An automated mapping of your internal skill names to a public taxonomy will do worse. Sample it, have a human review the mappings that drive decisions, and record the match type so a reader knows whether they are looking at an exact equivalence or an approximation.
The checklist before you publish a single skill record
- One spine taxonomy named, with the reason written down.
- Eight to twenty decision-carrying skills per role, not the full catalogue.
- A proficiency scale with behavioural anchors, consistent across skills.
- Evidence type stored as a mandatory closed-list field.
- Date of evidence on every claim.
- Assessment conditions and integrity context on every assessed claim.
- Taxonomy identifier as the key; label as display text only.
- Crosswalk match type recorded wherever a mapping was applied.
When a plain taxonomy is genuinely enough
If the only job is workforce analytics — counting how many people work with which technologies, spotting concentration risk, sizing a training cohort — labels alone are fine, and adding evidence fields to a headcount exercise is wasted effort. The moment a record is used to decide about an individual, or is shown to anyone outside the team that produced it, the evidence fields stop being optional.
Takeaway: choosing a taxonomy is the easy part and it is where most skills programmes stop. The fields that make skills data trustworthy — level, evidence type, date, conditions, identifier — are the ones no public taxonomy supplies and every downstream reader needs.