We hear from customers that they want to focus more on foundational skills. The conversation then tends to stall at the same point, because there is typically little clarity about what those skills actually are. The phrase is doing a great deal of work and carrying very little meaning.

Part of the reason is that the data underneath the conversation was never built for it. Most skills taxonomies describe tools. A person knows PyTorch, or knows Salesforce. That record goes stale quickly: a library that dominates this year is legacy in three, and every insight built on it expires with it. It is also barely transferable. Two people listing Python tells you nothing about whether one could move into the other's role.

Underneath the tools sit things that do not change. The mental capacities a person brings to work are the same in 1990, today, and in 2040. At Draup we have been advocating for four layers of skills, and this is the bottom one. We call them root skills, and they are what a skills ontology needs at its base to stay valid as tooling churns.

What breaks when the taxonomy is built on tools

Skills taxonomies built on tools are obsolete on arrival. When the tool changes, the data changes with it, and every workforce decision resting on that data has to be made again from scratch. The taxonomy is not wrong on the day you build it. It expires, and every insight built on it expires with it.

The second failure is comparison. A tool-based record cannot tell you whether two roles make similar demands when they share no software, so the genuine adjacencies for internal mobility stay invisible in the data. What a skills ontology needs underneath it, then, is a layer that holds still.

Four layers, connected in one direction

• Root skills · The raw mental capacities the work runs on. Working memory, visualization. These change essentially never.

• Core skills · The domain knowledge the role is built on. Recursion, differential diagnosis. These change at a moderate pace.

• Tech stack skills · Tools, languages, platforms. Python, Epic, SolidWorks. These change fast.

• Soft skills · How a person operates. Persistence, collaboration. These change slowly.

The layers connect in one direction only. A tool is used to apply a core skill, and a core skill demands certain root skills. A tool never maps straight to a root skill. Python serves algorithms, data analysis, and web services, and each of those makes different mental demands. The skill belongs to the work, not to the tool.

The skills ontology: 57 root skills across eight families

We did not invent these skills. They are merged from two established sources: O*NET Abilities, built by the US Department of Labor from surveys of job incumbents and occupational analysts, and Cattell-Horn-Carroll theory, the dominant psychometric model of human cognitive abilities. After cleaning and de-duplication, 57 root skills remain across eight families.

Reasoning holds 10, including deductive and inductive reasoning, problem sensitivity, and originality. Verbal holds 7, including oral and written comprehension and grammatical sensitivity. Memory holds 8, including working memory capacity, attentional control, and visual memory. Quantitative holds 3. Visual and spatial holds 9, including visualization and spatial scanning. Auditory holds 6, including speech and sound discrimination. Attention and speed holds 6, including perceptual speed, selective attention, and time sharing. Psychomotor and tactile holds 8, including control precision, finger dexterity, and kinesthetic and tactile sensitivity.

That last family matters for skilled trades, clinical work, and manufacturing. A purely desk-based taxonomy can set it aside, leaving 49. Cattell-Horn-Carroll also defines a knowledge domain, the acquired stores such as mathematical and statistical foundations. We exclude it from the root layer by design, because acquired knowledge is learned and therefore belongs to the core layer above rather than to the capacities the work runs on. This version of the paper deliberately goes no further into those knowledge-based skills.

The test that stops every core skill looking identical

For each core skill we ask what the work actually demands, then identify which root skill would cause failure if it were absent. The question is deliberately narrow: a person with normal ability in everything except X would specifically get what wrong in this core skill?

If the failure would be true of most core skills in the domain, that root skill is supporting. It is real, but it does not distinguish. If the failure is specific to that core skill, it is primary. Only primary skills carry information, and this distinction is what stops every core skill looking the same as every other.

The results are more discriminating than they sound. Reading engineering drawings resolves to visualization. Diagnosing a machine by sound resolves to speech and sound discrimination. Calculating a patient dose resolves to number facility. Spotting patient deterioration resolves to problem sensitivity. Planning delivery routes resolves to spatial scanning. In the full worked example, eighteen tasks drawn from six unrelated industries resolve to seventeen distinct root skills, with only one shared between them. The vocabulary separates genuinely different kinds of work instead of collapsing everything into a handful of generic labels.

Where the AI boundary actually falls

The automation question is usually asked at the level of the job title, which is why it so rarely produces a usable answer. Asked at the level of root skills, it becomes tractable.

Models are strong on some root skills and weak on others, and the boundary does not fall where intuition puts it. Written comprehension, lexical knowledge, and quantitative reasoning are increasingly cheap to buy from a model. Problem sensitivity, noticing that something is wrong before anyone has named what, is not. Neither is time sharing under real consequence, nor the tactile judgment in a sterile compounding step or in a hand on a machine that sounds wrong. Two roles with identical tool stacks can sit on opposite sides of that line.

So the useful test is not whether a role is exposed. Break the role into tasks, take the primary root skill behind each one, and ask whether a model holds that capacity today. What comes back is not a percentage. It is one list of tasks to move and another list of tasks that stay, which is the difference between a redesign plan and a headcount number. Because the root layer does not churn, that map stays valid as the models improve. Only the boundary moves, it moves in one direction, and it can be tracked.

What the stable layer buys you

Exposure estimates built on tools get re-litigated every year. Built on root skills, they hold, and they resolve to specific tasks rather than to a score against a job title. The root layer itself never needs rebuilding when tooling changes, because tools connect to it through core skills.

Cross-industry comparison becomes possible. A nurse triaging patients and a dispatcher managing a fleet both load on time sharing, a connection that is invisible in any tool-based taxonomy. Transition mapping gets better: roles that share root skills are genuinely adjacent even when they share no tools, and roles that share tools but not skills are not. Every mapping also carries its reasoning, which is what the work demands and what would go wrong without the skill, so nothing arrives as a black box.

Three places to start

Root skills only matter if they change a decision. Here are three places to start.

• Re-run one transition map. Take a role you are actively redeploying from. Compare the adjacencies your current taxonomy suggests against the ones root skills surface. The gap between them is what tool-based data is costing you.

• Pressure-test one AI exposure call. Break a role into tasks, identify the primary root skill behind each, and separate what a model can carry from what it cannot. That distinction produces a redesign plan rather than a headcount number.

• Audit your critical roles for durability. Any role whose profile is entirely tech stack is a role you will be re-baselining every eighteen months.

None of this requires replacing the taxonomy you already have. A skills ontology built on root skills sits underneath it, and it gives the layers above something that holds still.

‍