What is the hierarchy from knowledge to outcome?

Knowledge is what you know (you understand regression). Skill is what you can do (you can build a regression model). Capability is what outcome you can reliably deliver (you can use data to make a defensible business decision). Performance is what you actually achieved (you evaluated a real investment and improved forecast accuracy). Outcome is what changed for the organisation (a better capital-allocation decision). Each level depends on the one below it, and each answers a different question.

Why does the distinction between skill and capability matter?

Because it decides what you are able to measure and what a measurement is worth. A skills inventory answers what skills exist in the workforce. Capability measurement answers whether a person can combine those skills to do the work successfully, at what level and on what evidence. Organisations that conflate the two end up with long skill lists, high confidence and no ability to predict whether anyone can actually deliver an outcome.

How is this different in AI work?

Prompt engineering is a skill. The capability an employer actually cares about is something like: effectively use AI to solve a customer-support problem while maintaining accuracy, privacy and appropriate human oversight. That requires problem framing, delegation, prompting, verification, domain knowledge, risk awareness, judgment and communication working together. This is why AI-literacy checklists predict so little — they measure tool familiarity, which is a skill, when the thing that matters is a capability.

How do you measure a capability rather than a skill?

You cannot measure a capability by asking whether someone knows a thing. You have to put them in a situation that requires the combination — a realistic problem with ambiguity in it — and score what they do against behavioural anchors for each underlying dimension, with the evidence attached. The output is a proficiency level per dimension, a confidence, and the evidence behind it, not a percentage on a quiz.

Skill vs Capability: The Difference and Why It Decides What You Measure

Ask a room of HR leaders to define the difference between a skill and a capability, and you will get agreement that there is one, followed by five different answers. The words are used interchangeably in job descriptions, competency frameworks, LMS catalogues and skills taxonomies — and that habit quietly corrupts everything built on top of them.

It is worth being precise, because the distinction is not academic. It decides what you are able to measure, and what a measurement is worth once you have it.

The two definitions

A skill is a specific learned ability to perform a particular task. SQL. Financial modelling. Negotiation. Data visualisation. Prompt engineering. Operating a CNC machine. A skill is something a person possesses and can apply, and it can usually be placed on a proficiency scale — awareness, basic, intermediate, advanced, expert.

So a skill record looks like this:

Skill: SQL · Proficiency: Advanced · Evidence: SQL simulation · Score: 82%

A capability is broader. It is the demonstrated ability to combine multiple skills, knowledge, judgment, behaviours and tools to achieve an expected outcome in a particular context.

Consider a capability like data-driven business decision making. That is not one skill. It needs SQL, statistics, business understanding, data visualisation, critical thinking, communication and judgment — working together, on a real problem, under real constraints.

Knowing SQL does not establish that capability. Plenty of people can write a flawless query and still reach the wrong conclusion, or the right conclusion and fail to convince anyone of it.

The full ladder: knowledge to outcome

Skill and capability sit inside a longer chain. Each level depends on the one below it, and each answers a genuinely different question:

Level The question it answers Example

Knowledge What do you know? You understand regression

Skill What can you do? You can build a regression model

Capability What outcome can you reliably deliver? You can use data to make a defensible business decision

Performance What did you actually achieve? You improved forecast accuracy by 18%

Outcome What changed for the organisation? A better capital-allocation decision

Read downward and it is a story about a person becoming useful. Read upward and it is a warning: you cannot infer any level from the one above it. A good outcome does not prove capability — the market may simply have moved in your favour. Strong performance does not prove skill, for the reasons we set out in performance vs capability. And a certificate proves knowledge, not the ability to apply it on a Tuesday under pressure.

Why the confusion is expensive

Most skills programmes operate one or two rungs below where the business actually makes decisions.

The organisation wants to know: can this person run a pricing review? The skills platform answers: they have Excel, pricing analytics and stakeholder management on their profile. Those are not the same statement, and the gap between them is exactly where hiring mistakes, failed promotions and stalled transformations live.

It shows up in three predictable ways:

Long lists, low confidence. A skills inventory grows to thousands of entries and nobody will make a staffing decision on it, because everyone privately knows a tagged skill is not a demonstrated one.
Training that doesn't land. You close a skill gap — the course is completed, the skill is ticked — and the work still doesn't get done, because the missing piece was the combination, not the component.
Interviews that test the wrong altitude. Candidates are quizzed on skills and hired for capabilities, so the interview predicts far less than anyone expects it to.

A quick test on your own framework. Take any entry in your competency library and ask: if someone were rated "advanced" on this, could they deliver a business outcome on their own? If yes, you have written a capability. If they would still need four other things to be true, you have written a skill — and you should stop expecting it to predict performance by itself.

Where this matters most: AI work

Nowhere is the confusion costlier right now than in AI.

Almost every organisation is measuring prompt engineering — a skill, and a fairly shallow one. But the thing an employer actually needs is a capability, and it looks more like this:

Effectively use AI to solve a customer-support problem while maintaining accuracy, privacy and appropriate human oversight.

Unpack that and it requires problem framing, delegation, prompting, domain knowledge, verification, critical thinking, risk awareness, judgment and communication — all at once, on a live problem, with a real consequence for getting it wrong.

That is why AI-literacy checklists predict so little. They measure tool familiarity. Tool familiarity is a skill. The capability is whether someone can hand the right work to a model, spot when the answer is confidently wrong, and own the decision afterwards. We break that down into ten measurable components in the AI-era capability framework, and the short version is that "can you use AI?" is the wrong question at the wrong altitude.

Three different markets, often sold as one

Once the distinction is clear, it also explains why the skills software category is so confusing to buy in. Three different questions are being answered by three different kinds of product:

What it is The question it answers What you get

Skills intelligence What skills does our workforce have, need, or lack? A map. Coverage, gaps, supply and demand.

Capability measurement Can this person combine those skills to do the work — at what level, under what conditions? A level, in context, with a confidence attached.

Capability proof What evidence supports that conclusion, how was it measured, how trustworthy is it, and how current? A defensible record you can show a candidate, a board or a regulator.

Most tools stop at the first. It is the easiest to build and the easiest to demo, because it needs no measurement at all — an import, a taxonomy and some inference will populate a dashboard. It is also the reason so many skills projects stall: a map of claims is not a basis for a decision. That is the distinction between verified, inferred and proven skills.

How you actually measure a capability

You cannot measure a capability by asking whether someone knows a thing, because the whole point of a capability is the combination. Three things have to be true:

The situation has to require the combination. A realistic problem, with ambiguity in it and something at stake — not a question with a retrievable answer. If a model could answer it from memory, it is testing knowledge.
The scoring has to name the parts. Judgment, framing, verification, communication — each scored separately against behavioural anchors describing what each level looks like, so a strong communicator with poor judgment doesn't average out into "fine".
The evidence has to travel with the score. What the person actually said or did, attached to the rating, with the date it was measured. A capability rating with no evidence behind it is just a more confident opinion.

Done that way, the output is not a percentage. It is a level per dimension, a confidence, the evidence, and a date — which is what makes it defensible six months later when someone asks why a person was or wasn't promoted.

The one-line version

Skill: a specific learned ability to perform a task.
Capability: the demonstrated ability to combine skills, knowledge, judgment, behaviours and tools to achieve an expected outcome in context.

Skills are the building blocks. Capability is the ability to put those blocks to work and deliver something. Both belong in your workforce data — but only one of them answers the question the business is actually asking, and it is not the one most organisations are collecting.

The takeaway

A skill is what you can do; a capability is what you can deliver. Knowing SQL is a skill. Making a defensible, data-backed business decision is a capability.
The ladder runs knowledge → skill → capability → performance → outcome, and you cannot infer any level from the one above it.
Most skills programmes operate two rungs below the decision they are meant to support, which is why the data never quite gets trusted.
In AI work the gap is widest. Prompt engineering is a skill; using AI responsibly to solve a real problem is the capability, and only the second one predicts anything.
Capability can only be measured in a situation that demands the combination — scored by dimension, with the evidence and the date attached.

This is the idea GoMeasure is built on. Skills are organised into one source of truth, then measured to a verified level with the evidence attached — so what you hold is capability, not a catalogue. See the Human Skills & Capability Platform, or talk to us about measuring one capability on one real role.

A skill is what you can do. A capability is what you can deliver.