When I argued that skills intelligence lives or dies on verification, that an inferred skill is only a plausible guess while a verified one is the thing you can safely build a promotion on, the pushback was immediate and fair. If verification is the standard, then someone has to verify, and the picture that jumps into everyone’s head is a company-wide examination hall. Every employee sitting tests. Every manager grading endless rubrics on a Friday afternoon. A workforce that already feels measured to death being asked to prove itself all over again.
The fear is well-founded, and it is what pushes most skills programmes to quietly retreat to self-report and inference, after which nobody trusts the data and no one can quite say why. So before any of the rest of this series works, I owe you this piece. How do you get verified signal across a whole workforce without making verification a second job for everyone in it.
The testing centre is a category error
The trap is buried in the word itself. We hear “verification” and we picture “examination,” and those are not the same thing. An exam is one instrument of verification, and it happens to be the most expensive, the most disruptive, and, awkwardly, one of the least reliable, because it measures how someone performs when they know they are being watched rather than how they perform when they are just doing the work. If your entire mental model of verifying a skill is sitting someone down to prove it, then of course verification sounds like a nightmare. You have taken the clumsiest tool in the kit and assumed the whole job looks like that.
The shift that unlocked this for me took a while to sink in. Verification works less like an event you schedule and more like a property you harvest from work that has already happened. The merged pull request, the closed enterprise deal, the resolved incident at 2am, the shipped design, the passed audit, the workshop someone taught, all of that is evidence a skill exists, produced as a byproduct of the actual job. The work already emits proof. Most of the time the honest task is not to manufacture a fresh artificial proof but to catch the proof the work is already throwing off and attach it to the right skill.
Stop treating verification as a test you add. Start treating it as evidence you collect from work that has already been done.
Verification is a ladder, not a switch
The other mistake is thinking of verification as binary, a skill is either inferred or it is tested, and everything in between is noise. In practice there is a whole ladder between those two, and each rung is stronger evidence bought at a higher cost. Naming the rungs is what lets you stop over-paying.
Two costs move in opposite directions as you verify deeper: the cost of verifying climbs while the cost of being wrong falls. Total cost bottoms out somewhere in the middle, and that low point slides right as the stakes rise. Climb past it and you are spending to shrink a risk that is already gone.
- Rung 0 · InferenceAn algorithm’s guess from work history, produced instantly and for nothing, and completely unconfirmed.
- Rung 1 · Self-attestationThe person simply claiming the skill, cheap and biased but a reasonable starting point.
- Rung 2 · CorroborationSomeone who actually saw the work confirms it, which costs very little and quietly kills the capability inflation that plagues self-report.
- Rung 3 · EvidenceA real artifact of the work is attached to the claim, the thing that shipped, the deal that closed.
- Rung 4 · DemonstrationThe deliberate task or assessment, the actual exam, the strongest signal and by far the costliest.
Let the stakes decide how high you climb
That last phrase carries most of the weight, so it is worth making it concrete. The right depth of verification for a skill is set by the worst decision that skill will ever feed, not the typical one. A skill that will only ever nudge someone toward an optional workshop does not need to be proven, a decent inference is plenty, because the cost of being wrong is a slightly mistargeted email. A skill that will decide a promotion, a pay band, or who gets to lead a safety-critical migration has to be evidenced or demonstrated, because the cost of being wrong there is a career, a lawsuit, or an outage.
Inference paints the whole grid pale, a plausible guess in every cell. Real verification effort concentrates on the handful of skills that actually decide something, so the map stays cheap almost everywhere and turns deep only where a wrong answer would hurt.
When you actually sort a workforce’s skills this way, the relief is enormous, because the distribution is lopsided in your favour. The overwhelming majority of skill data feeds low-stakes, high-frequency nudges where light verification is completely adequate. Only a thin sliver at the top ever feeds the decisions that demand real rigor. The testing-centre nightmare assumed you had to treat all of it like that thin sliver. You do not. You aim your expensive verification at the ten percent of decisions that can actually hurt someone, and you let the other ninety percent run on cheap, good-enough signal.
Inference is the first draft, not the verdict
Notice what this does to the role of AI inference, which part one was hard on. Inference is not the enemy of verification so much as its first draft. The machine is very good at reading the signals a workforce emits and proposing a skill profile for everyone, at a scale and speed no human team could match. Its mistake is only ever that it is unconfirmed. So you let it do exactly that, produce a draft for the whole organisation, and this is the part that matters, you make it attach a confidence score to every guess it makes.
Then you route. This is the piece most teams miss, and missing it is what kills the programme in one of two ways. If you send every inference to a human to confirm, your managers drown and the initiative dies of fatigue within a quarter. If you confirm nothing and trust the machine wholesale, you have simply automated your guesswork and rubber-stamped it. The escape from both is to route by only two questions: how confident is the inference, and how high are the stakes of what it feeds.
| Confidence | What it feeds | What happens |
|---|---|---|
| High | Low-stakes nudges | Left exactly as it is, no human ever touches it, and that covers most of the workforce most of the time |
| Shaky | Anything | Escalated up the ladder for a manager to confirm or for evidence to be attached |
| Any | A consequential decision | Escalated up the ladder for a manager to confirm or for evidence to be attached |
Humans stay in the loop where judgement matters, and stay out of the millions of loops where it does not. That is the difference between a system that scales and a pile of review requests nobody ever clears.
A verified skill has an expiry date
There is one more thing that keeps verification from becoming a testing centre, and it runs the other way, against the instinct to re-check everything on a tidy annual cycle. A verified skill is not verified forever. Skills decay, and they decay at wildly different speeds.
- MonthsFluency in a specific tool can lose half its value as the tool changes underneath you.
- A couple of yearsCommand of a particular framework fades.
- A very long timeDurable capabilities like judgement, facilitation, and the ability to lead a room hold their value.
A single verification decays like anything else, the red line drifting out of the range where you can act on it. A cadence tuned to the skill’s half-life re-checks it just as it reaches the edge, holding the rating inside the band you can trust. Fast-moving skills need a tight cadence; durable ones almost none.
This is a point the team at Workera makes well, and it changed how I think about the calendar. They attach a half-life to each skill domain and re-check some every couple of months, some twice a year, some annually, driven by how fast that specific domain actually moves. The lesson is that a uniform annual re-assessment, the thing most companies default to, is the worst of both worlds. It wastes effort re-proving durable skills that have not moved, and it lets volatile skills sit stale and wrong for eleven months at a time. Set the cadence to the decay, not to the fiscal year, and you spend your verification budget where it actually buys freshness.
Why the depth is also your defence
I want to add one argument that rarely shows up in the HR conversation and should, because it changes verification from a nicety into a necessity the moment real decisions are involved. The instant a skill rating touches a promotion, a pay band, or a termination, you are no longer in a talent-development conversation. You are in a legal one. In most jurisdictions a decision that affects someone’s livelihood has to be defensible, and “the algorithm gave them a low score” does not defend the decision so much as expose it. An inferred number with no evidence trail behind it is precisely the kind of opaque, unvalidated judgement that loses when it is challenged for bias or disparate impact.
The evidence ladder does more than get you closer to the truth. Its upper rungs are also what let you stand behind a decision when someone challenges it. “We promoted her because a model guessed she was strong” collapses under the first serious question. “We promoted her on demonstrated, evidenced capability, measured against a rubric a panel co-signed, with the artifacts on file” holds up. Climbing the ladder for high-stakes decisions is not bureaucratic caution but the thing that separates a decision you can stand behind from one you merely hope no one examines.
There are two ways a skill call goes wrong, and they cost very differently. A false positive puts someone on work they cannot do, and it fails in public. A false negative leaves real capability on the bench, and nobody ever notices the waste. An inferred profile quietly fills both red squares; verification is how you empty them, starting with the decisions where the error is most expensive.
The test it should never feel like
All of this only works if you keep sight of what a good verification system should feel like from the inside, to the person being verified. Get it wrong and it feels like surveillance, or like being examined, and people withhold, game it, or opt out, and the data curdles. Get it right and it feels like something quite different, like the system finally noticing what you actually did. The verified profile that works is the one an employee experiences as recognition rather than as a test, their shipped work and closed deals and solved problems finally being credited instead of forgotten at review time. If the workforce experiences verification as “prove yourself again,” you have built the testing centre after all. If they experience it as “the system can finally see my work,” you have built the thing skills intelligence was always supposed to be.
So the answer to that first reply is no, verification does not mean a mutiny, because verification was never supposed to mean an examination. It means:
- Climb only as high as the decision demandsClimbing the evidence ladder exactly as far as each decision demands.
- Let the machine draftLetting the machine draft what it can and reserving human judgement for what is uncertain or consequential.
- Harvest the proofHarvesting the proof the work already produces instead of staging a fresh test to produce it again.
- Re-check on the skill's own clockRe-checking on the clock of the skill’s own decay rather than the calendar’s.
FAQ
Skills verification confirms that a person actually holds a skill instead of assuming it. An inferred skill is only a plausible guess, while a verified one is something you can safely build a promotion on. Most of the evidence already exists as a byproduct of the work, such as a merged pull request, a closed enterprise deal, a resolved incident or a passed audit.
There are five rungs, and each one is stronger evidence bought at a higher cost. Inference is an algorithm's guess from work history. Self-attestation is the person claiming the skill. Corroboration is someone who saw the work confirming it. Evidence attaches a real artifact of the work to the claim. Demonstration is a deliberate task or assessment, the strongest signal and the costliest.
The right depth is set by the worst decision that skill will ever feed. A skill that only nudges someone toward an optional workshop can run on a decent inference. A skill that decides a promotion, a pay band or who leads a safety-critical migration has to be evidenced or demonstrated.
No. Route each inference by two questions: how confident it is, and how high the stakes are of the decision it feeds. A high-confidence inference that only feeds low-stakes nudges is left as it is. Only shaky inferences, or ones about to feed a consequential decision, go to a manager to confirm or get evidence attached.
Set the cadence to how fast each skill decays, rather than a uniform annual cycle. Fluency in a specific tool can lose half its value in months, command of a framework fades over a couple of years, and durable capabilities like judgement and facilitation hold their value for a very long time.
