How do you prove a skill? A 6-level model of competency evidence

A Skills First approach shifts attention from formal labels toward competencies a person can actually demonstrate. That does not automatically solve the problem of how to assess those competencies.

OECD describes skills-first as an approach in which hiring and talent-management practices are adjusted to assess people on demonstrated skills. The report also points to the need for suitable assessment tools and skills frameworks. [1]

Replacing an "Education" section with a longer "Skills" section is therefore not enough. We also need a better way to explain why a skill claim should be considered credible.

Two people can list exactly the same skill while having completely different practical experience.

Imagine two specialists who both state:

Angular - advanced

The first completed a course, built a few personal projects and understands the framework basics.

The second spent three years developing a production application, owned the architecture of part of the system, carried out migrations between Angular versions and can point to concrete outcomes of that work.

On a conventional skills list, they may look very similar.

Only evidence placed in context starts to show the real difference.

The model is not designed to give people one universal score. Different professions produce different kinds of evidence, and not every project can be shown publicly.

Its purpose is to answer a simpler question:

how strong is the material supporting the claim that a particular competency is credibly represented?

The simplest level is the user's own declaration.

Examples:

• Angular
• Figma
• SEO
• team leadership
• B2B negotiation

This information is useful for search and discovery, but its evidential value is limited.

We still do not know:

• where the competency was used,
• for how long,
• at what scale,
• with what responsibility,
• with what outcome.

A declaration is the starting point, not the end of the assessment.

Evidence becomes stronger when we know where and in what context the skill was used.

Instead of:

Angular

we get:

Angular used for 2 years while developing a SaaS application for the logistics sector.

This still does not prove the quality of the work, but it adds important context:

• a real project,
• duration of use,
• area of application,
• nature of the environment.

At this level, the skill stops being only a label.

The next level appears when a declaration and experience can be linked to a real work artifact.

Depending on the profession, this may be:

• a working application,
• a code sample,
• a repository,
• an interface design,
• a prototype,
• a report,
• an analysis,
• a campaign,
• an article,
• documentation,
• a financial model,
• a photograph,
• an engineering design,
• a recording of completed work.

The artifact answers an important question:

can we see something that was actually created using this skill?

This does not mean that a portfolio is a formal competency test. Research on personnel selection nevertheless indicates that methods closely related to actual job tasks, including work samples and job-knowledge tests, can be useful predictors of job performance. The authors also stress that selection results need to be interpreted in the context of the use case, cost and limitations of the method. [2]

An artifact may still leave one of the hardest questions unanswered:

what exactly did this person do?

This matters especially in team projects.

An application may have been built by 20 people. A campaign may have involved an 8-person team. A rebrand may have included an agency, an internal marketing department and external consultants.

A stronger form of evidence is therefore a case study that identifies the individual contribution.

A useful case study should separate at least:

• the problem or objective,
• the scope of the overall project,
• the specialist's personal responsibility,
• the actions they actually performed,
• the competencies used,
• collaboration with other people,
• the outcome.

Instead of:

I built an e-commerce platform.

a better description is:

I was responsible for the frontend architecture, checkout implementation and payment-flow integration. The project was delivered by a five-person team.

The second description is more useful because it does not attribute the entire team's work to one person.

Evidence becomes stronger again when the work led to a specific outcome that can be described without vague language.

Examples:

Frontend
Reduced the main-view loading time from 4.2 s to 1.8 s.

UX
Reduced abandonment of the registration form after redesigning the flow.

Marketing
Reduced cost per lead while maintaining comparable traffic quality.

Sales
Opened a new customer segment and closed a defined number of contracts.

Operations
Reduced a process from several days to several hours.

Not every profession can or should express an outcome as a percentage or monetary value. Metrics should not be invented merely to make a profile look impressive.

The useful question is:

what changed because of this work?

The strongest level in this model appears when at least part of the information can be verified independently of the profile owner's own claim.

This may include:

• a publicly available project,
• a repository with contribution history,
• a public publication,
• confirmed participation in a project,
• a client or colleague reference that may lawfully be published,
• an outcome that can be independently confirmed,
• an official credential where it is genuinely relevant,
• another source confirming specific work.

This does not mean that every project must be public.

Many valuable projects are covered by NDAs, trade-secret obligations or other confidentiality restrictions.

A lack of public evidence therefore does not mean a lack of competence.

It means only that the degree of independent verifiability is lower.

Level 1 - declaration
Angular.

Level 2 - context
Angular used for 3 years in SaaS applications.

Level 3 - artifact
A public application, repository or another work sample that can be shown.

Level 4 - individual contribution
Responsibility for selected module architecture, shared components and application migration.

Level 5 - outcome
An optimization reduced the main module startup time from 4.2 s to 1.8 s. The values are illustrative.

Level 6 - verification
The outcome and contribution can additionally be confirmed by a public project, change history, a reference or another independent source.

Two pieces of evidence at the same level may have very different value. Five additional dimensions help interpret their quality.

1. Relevance - does the evidence really relate to the competency being assessed?

2. Recency - when was the competency used and how much does recency matter in this field?

3. Authorship and responsibility - do we know what the person actually did?

4. Context - what were the scale, complexity, responsibility, resources and working conditions?

5. Verifiability - is there an independent way to confirm at least part of the information?

Relevance

A project in which a technology was used only marginally is weaker evidence than one in which that competency was central to the work.

Recency

The importance of recency depends on the field. In some areas, experience from ten years ago can still be highly valuable. In others, tools and practices change quickly enough that recent use matters greatly.

Authorship and responsibility

The larger the project and team, the more important it is to separate the result of the whole project from the specialist's individual contribution.

Context

The same result may carry different weight depending on project scale, time constraints, resources, responsibility and problem complexity.

Verifiability

Independent verification is not always possible and should not always be required. When an independent source can confirm the outcome or contribution, however, it strengthens the credibility of the evidence.

A person can perform their part of a project extremely well even if the project ultimately fails commercially.

A person can also work on a highly successful project while having only a small influence on the final success.

It is therefore useful to separate three things:

1. Competency
Can the person perform a particular kind of work?

2. Contribution
Which part of the work were they actually responsible for?

3. Outcome
What changed as a result of the work?

Only the combination of these elements gives a fuller picture.

A certificate or another formal credential can be useful evidence, but its value depends on what it actually confirms and how it was obtained.

It may confirm, for example:

• completion of training,
• achievement of defined learning outcomes,
• passing a particular form of assessment,
• knowledge of a standard,
• satisfaction of formal requirements.

The European Commission describes micro-credentials as records of learning outcomes acquired through a short learning experience. The European approach emphasizes, among other things, transparency and quality. [3]

A certificate should not automatically be equated with proof that someone can independently perform complex work in a real professional environment.

A credential is therefore one possible element of evidence, and its meaning depends on context.

Being unable to show a project publicly should not erase valuable experience.

At the same time, NDAs, confidentiality duties, trade-secret protection, copyright and data-protection rules take precedence over the desire to show portfolio work.

A specialist should describe a project only to the extent permitted by their agreements, applicable law and the rights of other people and organizations. Removing the client name is not always enough if the remaining details can still identify the project, client, technology, results or confidential methods.

Where disclosure is permitted, it may be possible to describe:

• the industry at an appropriately general level,
• the nature of the problem without disclosing confidential information,
• the specialist's role and responsibilities,
• competencies used,
• the scale of the work only to the extent it can be disclosed,
• the type of outcome without publishing protected data,
• the approach at an appropriately general level.

If there is uncertainty about whether particular information may be published, the safer approach is not to disclose it until the agreement has been checked or permission has been obtained from the rights holder.

A competency-evidence system should not be designed as if every profession were software development.

A designer may show process, design decisions, a prototype and an outcome.

A developer may show a product, code, architecture or technical scope of responsibility.

A marketer may present a campaign, approach, responsibility and changes in results.

A salesperson may describe a market segment, the sales process, their role and the outcome without revealing confidential client data.

A Project Manager may show project scope, organization of work, constraints and influence on delivery.

A photographer may present completed work without inventing artificial KPIs.

The framework should be common at the level of principles but flexible in the type of evidence used.

1. Check where the competency was actually used.

2. Look for a work artifact or a concrete example of delivery.

3. Separate the specialist's contribution from the work of the whole team.

4. Examine the outcome when it can be meaningfully described.

5. Consider recency and how similar the previous experience is to the problem you need to solve.

6. Look for independent confirmation where it is possible and appropriate.

This shifts evaluation away from profile keywords and toward the actual fit between demonstrated competencies and a concrete need.

The framework is intended to organize information and support judgment. It should not be treated as an automatic verdict on hiring, rejecting a candidate or starting a professional engagement.

You do not need level 6 evidence for every competency.

It is more useful to review your most important skills and ask:

• where did I use this skill?
• what problem was I solving?
• what exactly did I do?
• do I have a work artifact?
• what was the outcome?
• can I describe it without breaching confidentiality?
• can a person or source confirm my contribution?

Even moving from:

Figma - advanced

to:

I designed the onboarding flow for a B2B application and was responsible for research, prototyping, usability testing and the final design system

changes the quality of information available to someone viewing the profile.

A Skills First approach only becomes meaningful when the word "skill" represents more than another tag.

If competencies are to be one of the main ways people discover and compare specialists, they should be connected with the best available context:

experience -> portfolio -> individual contribution -> outcome -> verifiability.

Not every competency will reach the highest level, and it should not have to.

The goal is not to create mandatory bureaucracy around every item on a profile.

The goal is to let specialists explain why a skill claim should be credible, and to help people looking for expertise make a better-informed decision.

1. Specifics instead of declarations - show where and how the competency was used.

2. Individual contribution instead of the whole team's success - separate your work from the result of the whole organization.

3. Outcome instead of a duties list - where possible, show what changed because of the work.

4. Context instead of a number alone - a metric without conditions can lead to incorrect conclusions.

5. Verification where possible - independent confirmation strengthens credibility, but its absence does not invalidate the competency.

A professional profile should not force the reader to guess what really sits behind a skills list.

A declaration helps a competency get discovered. Evidence helps it get understood.

The six levels can be reduced to a simple path:

1. I say I can do it.
2. I show where I used it.
3. I show what I created.
4. I explain what exactly I did.
5. I show the outcome.
6. I enable independent confirmation where possible.

The more of these questions we can answer, the less we have to rely on the claim alone.

That is when Skills First becomes more than simply changing the order of information on a profile.

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
Open source

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
Open source

[3] European Commission - A European approach to micro-credentials
Open source

Methodological note: sources [1]-[3] provide broader context on Skills First, competency assessment and credentials. The 6-level model of competency evidence itself is an original conceptual model described in this material and is not presented as a result of those publications.