Job title
Job Titles Are Local Claims, Not Portable Capability Profiles
A title can describe hierarchy, history, pay or a hiring manager's imagination. It cannot safely serve as the canonical profile of a person's skills.
What the wrapper says
A local job title and family code organise one employer's roles and compensation model, while an occupation describes recurring work in the wider labour market.
The all-clear
Titles, occupation codes and job families make communication, reporting, market comparison and pay governance more manageable when they remain distinct from person-level capability evidence.
What is durable
The tasks, knowledge, judgment and scope a person can demonstrate.
Somebody wants every employee matched to a learning path from the job_title field.
Fine.
Great.
A string.
The most stable thing in corporate life, apart from the coffee machine that has read OUT OF SERVICE since the reorganisation.
The extract contains Senior Software Engineer.
And Software Developer II.
And Platform Engineer.
And Code Wizard, created during a merger when everyone had very good intentions and no shared HRIS.
Your system now has to decide who should learn architecture, who should learn test automation, and who is eligible for the internal platform role.
It sees nouns.
You need capability.
That is not a complaint about titles.
It is a data-model boundary.
A title arrives carrying other people’s business
Titles do useful work inside an employer.
They make an organisation chart readable.
They signal a level.
They fit on an offer letter.
They help a manager explain why the person who owns the quarterly close is not also expected to run the acquisition process.
Sometimes they also carry the accumulated sediment of an employer’s history.
An acquisition.
A legacy pay grade.
A business-unit convention.
A hiring manager who wanted everyone to feel special on a Tuesday.
All perfectly normal.
But the string does not tell your system which task the person performs, at what level of judgment, with what evidence.
It cannot, because a title is a local claim. A label made meaningful by one employer, one job architecture, one market and one history.
Take the reassuring title Software Engineer.
One employer uses it for the person who designs the system. Another uses it for the person who implements a defined design. A third uses it for the person who builds the test pipeline.
A fourth calls that last person a Quality Engineer, because that was the available requisition template in Workday.
All of them may write code before lunch.
The work boundary is still different, and the national classification separates those three kinds of work into three occupations with three codes.
The local title neither resolves nor erases that difference.
Treat all of those strings as portable capability profiles and you have built a very efficient way to recommend the wrong course.
The durable object is the work demonstrated
An individual record has to answer a less decorative question.
What can this person demonstrate?
That means tasks, knowledge, judgment and scope.
It means evidence.
A validated project, an assessment, a work outcome.
A title can supply context.
Those are different jobs.
The difference becomes visible in how occupational data is actually built. Skill and ability ratings run on importance and level scales with behavioural benchmarks, describing what an occupation typically demands.
Those scales may inform an occupational profile.
They do not prove that an employee called Senior Developer has reached that level. Any more than an org chart proves that somebody has read the documentation.
The durable object is demonstrated capability at a stated scope.
The title is the wrapper that arrived with it.
Titles are not useless, which is the awkward part
None of this argues against job families, occupations or titles.
They solve different administrative problems, and those problems are real.
A job family gives compensation, reporting and career administration a coherent structure.
An occupation code supports labour-market analysis.
A job profile supports internal role design.
A title helps people communicate.
The finance functions make the case without help from a taxonomy consultant.
Corporate accounting handles reconciliations, payroll and statutory reporting.
Financial planning handles forward-looking budgets and forecasts.
Corporate development handles acquisitions and transactions.
Those are not interchangeable roles because everyone owns a spreadsheet.
The problem starts only when one of those labels is promoted from useful context to a complete account of a person.
The administrative home is not the biography.
A familiar title is not a valid match
Compensation teams already know this, because the survey process has rules for exactly the point where title matching becomes embarrassing.
A benchmark match is not permitted on the title. It requires that the internal role’s core accountabilities, technical scope and required capabilities substantially match the survey description.
Identical titles carry very different responsibilities across companies.
That is not a fussy compensation exception.
It is a general lesson in data hygiene.
The same comparison has to happen before you link a local role to an occupation or a learning path.
Does the role create architecture, implement a defined design, or validate a system?
Does it own a runtime platform or production application code?
Does it require predictive statistical modelling, or a customer-facing feature service?
Those questions are checkable.
The title is not.
The title can hide a boundary that matters
Occupation categories are not person records either.
But their boundaries show exactly what a title-only model fails to see.
In clinical nursing, Registered Nurses are 29-1141.
Nurse Practitioners are 29-1171.
Licensed Practical and Licensed Vocational Nurses are 29-2061.
The roles differ in clinical assessment, care-plan authority, diagnostic and prescriptive authority, and execution under supervision.
Roughly 3.2 million people sit in the first category.
Around 280,000 in the second.
About 655,000 in the third.
Three distinct task boundaries, rather than one generic nursing label.
That is not a reason to infer that everyone inside a title has identical capability. It is a reason for your matching system to be careful about scope and authorized work.
Transport gives a less subtle version.
Heavy and Tractor-Trailer Truck Drivers are 53-3032, operating vehicles above a gross weight rating of 26,000 pounds. Light Truck and Delivery Services Drivers are 53-3033, at or below it.
The first occupation involves a Class A commercial licence, interstate freight and electronic logging devices. The second emphasises local delivery, proof-of-delivery scanning and physical handling.
The local title Driver is doing very little explanatory work here.
Somebody will still match it to a learning module called Driver Essentials.
The module will have a stock-photo dashboard, fourteen slides, and a completion badge shaped like a steering wheel.
AI turns the shortcut into a finding
Titles emerged locally.
Job families emerged inside employers.
Occupation systems emerged to classify work across a labour market.
Then workforce platforms arrived and reasonably asked which people could move, learn, qualify or succeed into a role.
Then AI arrived and asked the same question at speed.
The model sees clean fields.
Title.
Family.
Level.
Profile.
Occupation code.
It infers skills from title strings, because that is the field you supplied. It infers a capability difference between Software Developer II and Senior Software Engineer, because their names differ.
It takes a family label as proof that a person cannot have demonstrated a capability elsewhere.
None of that is a mysterious model defect.
That is a local naming convention promoted to empirical evidence.
Now two employees doing the same work get different learning recommendations, different mobility matches, different reported gaps.
Because their titles entered the system differently.
Your recommender has discovered an HRIS migration and labelled it workforce intelligence.
The remedy is not to demand one global title per person. That turns the title catalogue into an international treaty, and the committee will require snacks.
The remedy is to keep the objects separate.
Store the claim beside its meaning
Give yourself a canonical role.
An internal record of expected outcomes, scope, family, level and neighbouring-role relationships, with an identifier that is not the display title.
Retain the local title with provenance.
Source employer.
Business unit.
Location.
Effective date.
Any naming rule that makes the string meaningful.
Retain the family and level definition that applied when the record was created.
A job profile is an organisational object.
It is not an employee’s permanent identity.
Attach capability records to the canonical role, and do not make them exclusive to its family.
Then attach evidence to the person.
A project.
An assessment.
A validated outcome that shows the task and judgment actually demonstrated.
A role may expect a capability.
A person record has to establish it.
For external matching, preserve the occupation identifier and the particular task or descriptor basis for the link.
Occupational descriptors are collected through structured questionnaires, from a sample of incumbent workers, on a rolling schedule across a few hundred occupations a year. That is a collection method with a scope and a refresh history.
It is not an automatic biography for everyone holding a similar title.
So before your AI system recommends a move, audit the inference.
Was the capability attached because of a title string?
A family code?
A canonical role profile?
An occupation descriptor?
Or evidence of demonstrated work?
Was the cited work architectural creation, implementation, validation, operational reliability, or something else again?
Can a reviewer see the distinction?
If not, your system is not matching capability.
It is matching whatever somebody typed into a requisition form.
The title can stay on the door
You do not have to abolish titles to stop mistaking them for people.
Keep titles for communication.
Keep job families for pay and governance.
Keep occupations for labour-market classification.
Keep job profiles for internal role design.
But let the worker record hold the durable thing. Demonstrated tasks, knowledge, judgment and scope, with the evidence attached.
That model gives a more honest answer when a manager asks whether an employee is ready for a new role. It can compare evidence against the canonical role’s requirements.
It can identify an actual learning need.
It can recognise equivalent work performed under a different local title.
And it can leave Code Wizard exactly where it belongs.
On the offer letter.
What the record establishes
- Separate a local display title, an internal canonical role and an external occupation record.
- Record local title provenance and retain the job profile, family, level and effective definition that give it meaning.
- Attach project, assessment or validated-work evidence to capability claims rather than deriving them from a title string.
- Use role-content matching rather than title matching for compensation surveys and external occupation links.
- Use O*NET worker-oriented and job-oriented descriptors to describe work without treating an occupation as a person record.
- Audit title-based AI recommendations for unsupported skill inferences, job-profile changes and occupation-boundary errors.
Asked in the review
- What is the difference between a job title, a role and an occupation?
- A job title is a local display label. A canonical role is an employer's defined record of expected outcomes, scope, family and level. An occupation is a wider labour-market classification of recurring work. The three can be related, but they answer different questions: what an employer calls a role, what that role requires, and how work is classified outside the employer.
- Why is a job title not proof that someone has a skill?
- A title can indicate seniority, reporting position, compensation convention, hiring history or a local naming preference. It does not record the tasks a person performed, the knowledge applied, the judgment exercised or the scope achieved. A capability claim needs evidence such as validated work, a project or an assessment, with the expected autonomy, complexity and scope stated separately.
- What should an organisation store with a local job title?
- An organisation should retain the local display title with its source, location or business context, and connect it to a canonical role identifier. The canonical role should retain its job profile, family, management level, pay-grade relationship, expected outcomes and effective definition. This preserves what the title meant when it entered the system instead of treating the string as a permanent capability profile.
- Can two people with different titles be matched to the same role?
- Yes. Two local titles can map to one canonical role when their expected outcomes, scope and capability requirements are the same. The titles remain local representations, while the role supplies the common internal reference. The mapping should preserve the source title and its context so later analysis can distinguish a naming difference from a real difference in work or capability.
- Why is title matching unsafe for compensation surveys?
- Title matching is unsafe because identical titles can carry very different accountabilities, technical scope and required capabilities across employers. WorldatWork's 80 percent content-match rule permits a survey benchmark only when at least 80 percent of those elements align with the external job description. A title can help locate candidates for review, but it is not the evidence that validates the match.
- Does a job family describe a person's full capability?
- No. A job family organises related job profiles for an employer's architecture, including career tiers, compensation and functional ownership. One family commonly links to 6 to 12 job profiles. The family gives a role an administrative home, but a person's capability record requires evidence of demonstrated tasks, knowledge, judgment and scope, including capability gained in another family.
- What does an occupation code tell an employer about a person?
- An occupation code describes a standardized category of work, not a complete person-level profile. O*NET's Content Model uses 277 descriptor variables across six domains to describe occupations, separating worker-oriented attributes from job-oriented requirements. That structure supports comparison of work, but it does not establish that every person holding a local title has every skill associated with the occupation.
- How should an organisation distinguish a software developer from a programmer or tester?
- The organisation should compare the work rather than substitute titles. SOC 15-1252 Software Developers cover architecture and the translation of requirements into scalable technical systems. SOC 15-1251 Computer Programmers implement defined designs. SOC 15-1253 Software Quality Assurance Analysts and Testers focus on verification, defect discovery and performance testing. A matching decision should preserve those different task boundaries.
- What evidence should support a capability claim?
- A capability claim should be supported by a project, assessment or validated work outcome that shows the person performed the relevant task or exercised the relevant judgment. The evidence should state the required autonomy, complexity and scope. A title, family identifier, pay grade or occupation code can provide context, but none of those administrative labels is evidence of performance by itself.
- Why do FLSA job records need duties instead of only titles?
- FLSA exemption classification depends on a salary-basis test, a salary-level test and a duties test. The duties test assesses whether primary daily duties satisfy the criteria for an Executive, Administrative, Professional, Computer or Outside Sales exemption. The corpus states that job titles alone have zero legal standing and that teams conduct 100 percent compliance audits of job-profile duties before setting the HRIS exemption flag.
- How can AI make title differences look like skill differences?
- An AI system can treat tidy title fields as if they were direct capability evidence. It may infer a different skill bundle from two local names even when the people perform the same work, or it may treat an occupation boundary as an individual deficit. The result routes similar employees toward different learning or mobility paths because naming history entered the model as empirical workforce data.
- What should be checked before AI recommends a learning path or internal move?
- The organisation should check the local title's provenance, the canonical role definition, the job-profile and family version, the external occupation used, and the evidence for each inferred capability. It should also test whether the relevant work is architecture, implementation or validation; O*NET distinguishes skills from tasks and work context. Recommendations should expose unsupported inferences for human review rather than turn labels into conclusions.