Occupation Codes Do Not Measure the Person Inside Them

Every person in the service team has the same occupation code.

occupation_mapping_MASTER_final.xlsx also has a column named critical_skills, and the sort of confidence that only arrives after a steering committee has approved the colour palette.

Every person in a service team has the same code.

So the workforce plan reports that the team has plenty of the associated skills.

Then the system needs somebody who can take responsibility for a specific task, in a specific operating context.

And the room becomes very interested in what the code actually means.

This is not a failure of occupational classification.

It is a failure to notice what has been classified.

An occupation describes recurring work. A capability record describes what a person can demonstrate.

Those objects meet often.

They are not the same object, despite their longstanding friendship inside your HRIS.

An occupation is a useful average with a job to do

O*NET-SOC 2019 is aligned to the 2018 Standard Occupational Classification.

It carries 1,016 occupational titles, 923 of them with descriptor data, and encompasses more than 55,000 jobs.

Underneath it sits a four-level hierarchy of major groups, minor groups, broad occupations and detailed occupations.

That is a serious piece of labour-market infrastructure.

It lets a workforce planner compare recurring work at a scale no local job architecture can manage.

It gives labour-market reporting a shared language.

It gives a learning team a credible starting point when the question is, broadly, what work might be changing around a role.

The code is doing exactly that work.

The complication begins when somebody silently upgrades it from a description of an occupation to a measurement of a person.

The O*NET Content Model does not make that mistake.

It separates Worker Characteristics, Worker Requirements and Occupational Requirements, then distinguishes them again across six domains.

It holds 277 standardized descriptors, covering abilities, skills, generalized work activities, more than 2,000 detailed work activities, and work context.

That is not a blob called “person who has this occupation code.”

It is a structured acknowledgement that work has tasks, conditions, requirements and different kinds of human contribution.

An occupation can make a sensible discovery signal.

Look here.

These activities may be relevant.

It cannot establish that a particular employee has performed all of them, performs the ones that matter, or can exercise judgment when the setting changes.

This distinction is extremely rude to a dropdown menu.

The person inside the code is not the median descriptor

Any detailed occupation describes a centre, not its members.

The code says what the work usually involves.

It says nothing about which parts of that work a given person has done, or how recently, or at what level of responsibility.

That is useful when comparing labour-market work.

It is not a biography.

One person under a code may have designed a fault-tolerant system. Another may have spent recent years working inside somebody else’s architecture.

A third may have unusually deep production knowledge and no design experience at all.

Somebody will have strong opinions about Kubernetes that nobody asked for, and no experience at all of the task your planning model has marked “covered.”

The category gives you a plausible place to start asking questions.

It does not finish them.

The same issue shows up in physical work, where vague inference gets expensive faster.

The work-context descriptors distinguish hazardous contaminants, high-voltage electricity, time pressure and consequence of error.

Two workers can share an occupational code and meet a substantially different combination of those conditions.

Nobody would sensibly infer authorization for a hazardous task from a nearby string in a table.

Your capability system should be no less careful about judgment, task coverage, and technical work that merely looks less dramatic on a dashboard.

Some codes announce their own limits

O*NET-SOC 2019 has 93 title-only occupations.

They have no descriptor data at all.

One of them, 11-9039.00 Education Administrators, All Other, means education administrators not listed separately.

That is a residual category.

It is not a concealed competence model for everyone who landed there after a migration.

The same edition lists a handful of New and Emerging occupations.

Penetration Testers, at 15-1299.04, is described as evaluating network system security through simulated internal and external cyberattacks, using adversary tools and techniques.

Excellent occupational description.

Useful discovery signal.

Not proof that a local employee with a related title has performed that task, used those techniques, or has the judgment to do it safely.

Which is where planning reports acquire their oddest result. A capability surplus, because everyone has been assigned the right occupation code.

Accompanied by an urgent search for the person who can actually do the critical work.

The sheet is not lying maliciously.

It has been asked to answer a question its cells do not contain.

The version is part of the meaning

Occupation codes also arrive with history, which is inconvenient for the theory that a code is a permanent fact about a person.

The 2010-to-2019 crosswalk lists 1,164 occupations.

Among them, 107 changed code and 75 changed title.

Administrative Services Managers moves from 11-3011.00 to 11-3012.00, keeping the same title.

The code changes.

The work record does not suddenly become a new human being.

Elsewhere, 11-9031.00 keeps its code while changing from “Education Administrators, Preschool and Childcare Center/Program” to “Education and Childcare Administrators, Preschool and Daycare.”

The label changes.

Your database should not pretend it has discovered a new capability.

Crosswalks are not identity machines either.

Both 11-1011.00 Chief Executives and 11-1011.03 Chief Sustainability Officers map to the single 2018 SOC code 11-1011.

Aggregate at that level and the distinction disappears, in perfectly valid arithmetic. Reading the result backwards will not reconstitute it through enthusiasm.

So store the source classification, the edition, the identifier, the captured label and the local role context.

Preserve the mapping direction, and the detail the mapping loses.

Ordinary data stewardship.

Not an invitation to form a task force called “Ontology Futures.”

The classification is earning its keep, which is the trap

None of this argues for abandoning occupation codes and returning to a shared drive containing CV_final_final_revised.pdf.

Occupational classifications support labour-market comparison precisely because they aggregate recurring work.

The descriptor architecture gives planners a consistent way to examine tasks, skills, knowledge and context across data-level occupations.

Its collection design exists to build population-level occupational information. Not to turn one manager’s impression into a national fact.

That aggregation is the benefit.

It is also the boundary.

You can use an occupation to find relevant learning.

To identify adjacent work.

To understand external demand.

To form a workforce-planning hypothesis.

You should not use the code alone to certify an individual.

Or allocate safety-critical work.

Or decide that a skills gap exists.

Or declare that a critical capability is covered.

The classification stays useful when you ask it the question it was built to answer.

The tidy field wins, as usual

Occupation codes are tidy fields.

Titles are tidy fields.

A model can ingest both in an afternoon, with a satisfying number of rows and no need to disturb the people doing the work.

Then it infers skills, recommends learning, matches people to projects, and announces a capability position.

It sees a code linked to a descriptor profile, and reasonably assumes the profile describes the person.

Your system has just converted a population-level relationship into an individual claim, because the input made that conversion look tidy.

AI did not invent the ambiguity.

It operationalises it at a speed that makes the quarterly workforce report look admirably decisive.

This is the hinge.

Occupational classifications grew to make recurring work legible inside a labour market.

Skill systems organise related but different objects.

Then global platforms placed all of them beside employee data and asked what every field meant.

An occupation code alone does not survive that question.

The model may propose that a role is likely to need a capability.

Fine.

Keep the source, the edition, the mapping scope and the confidence, and mark the result as an inference.

A demonstrated capability sits in a separate record, with the task, the evidence, the work context and the required judgment.

Then the recommendation can be useful without becoming a quiet assertion about a person.

Make the code a beginning, not a verdict

The practical design is not glamorous.

Keep an occupation record for labour-market comparison.

Source, version, code, title, crosswalk relationship.

Keep a role record for your actual work and its expected outcomes.

Keep capability records for the specific tasks, knowledge and judgment that matter, with direct evidence attached wherever the work is critical.

Then connect them with scoped relationships.

An occupation may suggest a task is commonly relevant.

A role may require it.

A person may demonstrate it in a stated context.

Three separate statements.

Which is why they deserve three separate fields.

Route title-only, residual and unmapped records to review.

Treat a new or emerging occupation as a prompt to inspect the work.

Keep the uncertainty visible when a mapping is broader, narrower or many-to-one.

Then the workforce-plan question gets better.

Not: how many people share this occupation code?

But: who can demonstrate the critical task, with the relevant knowledge and judgment, in this context?

That is a less elegant cell in the spreadsheet.

It is, unfortunately, the person inside it.