Job exposure vs skills gap: Occupational Information Network (O*NET) or postings for 2026?

This guide compares O*NET and job postings for measuring skills gaps. It sets one rule for choosing the source by question type.

How O*NET and postings differ at source

The O*NET Database is updated quarterly, according to the O*NET Resource Center, and its public Occupation Update Summary documents data currency for each occupation. Occupational analysts synthesize survey inputs into standardized profiles, so a cited profile is a curated occupation-level record rather than a live market feed. Before citing any profile, check the Occupation Update Summary to see when that occupation was last refreshed; the quarterly cycle is the mechanism, but the summary is the verification step.

Job postings are a different instrument: scraped, deduplicated, and classified advertisements collected from employer sites and boards. Their strength is speed, with freshness measured in days to weeks, but their weakness is classification noise. Titles are noisy, and the same job can appear under multiple occupation codes, so a posting count is a demand signal with an error term rather than a clean occupational inventory.

The structural consequence is that O*NET changes slowly by design through its quarterly refresh, while postings change quickly but carry the noise of employer language and duplicate ads. O*NET tells you what an occupation contains; postings tell you what employers currently demand. The source is therefore chosen by the question, not by preference: durable, occupation-level requirements and transitions belong to O*NET, while emerging, employer-specific demand belongs to postings.

Because the two sources measure different things, a single posting spike should not be read as a change in an occupation's durable skill set, and a stable O*NET profile should not be read as proof that employer demand is unchanged. Verify the occupation's last refresh in the Occupation Update Summary before treating O*NET as current, and treat posting-derived skill lists as demand hypotheses until they are reconciled with the occupation's standardized content model.

The evidence: what each source actually shows

The O*NET Resource Center is the named source for treating O*NET as a maintained, auditable dataset. When a skills-gap claim depends on occupational contents, the first check is whether the underlying profile can be traced to that maintained source rather than to an informal scrape or an undated extract.

Live postings answer a different evidence question. They show what employers currently demand, including newly worded skill requirements, but they are a flow of vacancies rather than a census of what an occupation contains. A posting can prove that at least one employer asked for a skill on a given day; it cannot by itself establish the durable requirement set for the occupation. That is why postings are strongest for emerging, employer-specific demand, while O*NET is strongest for durable, occupation-level requirements.

The convergence example comes from worker-transition research on ResearchGate, "Worker Transition Across Formal and Informal Sectors": 6.84% of observed workers transitioned from informal to formal jobs, while 6.24% moved from formal to informal jobs. The two rates differ by only 0.60 percentage points, so the near-symmetric flows show that occupational composition shifts are measurable from structured data, not from postings alone.

Use those rates as a scale check, not a universal threshold. If a measured skill change is small relative to observed worker movement between formal and informal work, treat it as tentative until it persists across another O*NET cycle or is corroborated by postings.

If the change is large and persistent, the structured record is the better evidence for occupation-level requirements; postings then serve as the cross-check for whether employers are currently acting on that change.

For 2026 measurement, record the source, date, and occupation identifier with every claim; if a claim mixes O*NET contents with posting demand, label which part came from which source before comparing gaps. This labeling prevents a posting spike from being mistaken for an occupational change, and prevents a stable O*NET profile from being mistaken for current employer demand.

Options compared: which source wins when

The choice between O*NET and live postings should be made by the question, not by preference. If the decision concerns what an occupation contains, O*NET is the source; if it concerns what employers are asking for now, postings are the source. The table below assigns the winner by use case and states the check that justifies it.

O*NET wins when the claim must survive audit or comparison across years. Durable skill requirements, disability or vocational assessment, and occupational transition research all depend on a stable definition of the occupation; a standardized profile is easier to defend than a sample of advertisements. For disability or vocational assessment, the occupation content should be traceable to a maintained profile rather than inferred from hiring language.

Postings win when the claim is about current demand. Emerging tool demand, employer-specific requirements, and real-time hiring pressure change faster than occupation profiles, and postings carry firm-level detail that a standardized database cannot. The check is whether the question is about demand now, not about the occupation's durable content.

The tie-breaker applies to any postings finding with policy or hiring consequences: reconcile it to the nearest O*NET occupation profile before acting. If the sources disagree, report the O*NET figure as the baseline and treat the postings figure as the current-demand deviation. Do not let a posting spike override the occupation baseline without documenting the mismatch.

Before using either source, label the claim as occupation content or market demand. If a decision needs both, run the comparison and record which source supplied the baseline and which supplied the deviation.

Costs and numbers that matter

The expensive mistake is not choosing the wrong source once; it is letting one source answer both questions. Overbuilding on posting noise spends training capacity on skills that may be one employer's stack, while under-detecting real skill change leaves workers unprepared for requirements that have already moved. The cost is paid in months of misdirected training and in delayed response to genuine demand.

Trusting postings alone is risky because an ad is a hiring document, not an occupational inventory. A skill that appears in a small, unverified sample can look like market demand when it is really one team's tooling preference. If curriculum or retraining is keyed to that signal, the error scales with every posting counted without checking who posted it, how many employers are represented, and whether the skill is central or incidental to the job.

Trusting O*NET alone has the opposite failure mode. Its profiles are synthesized and refreshed on a quarterly cycle, so a tool or practice that emerged this year can be absent or weighted low even when employers already require it. The cost is not a bad profile; it is a slow recognition that the occupation's durable requirements have shifted before the standardized record catches up.

The cheap checks are denominator-first. For postings, compute the sample size per occupation and the share of those postings that mention the skill; record employer concentration, not just keyword frequency. For O*NET, record the profile's currency date and compare it with the skill's apparent emergence. These three numbers do not settle the question, but they prevent the common error of treating a thin or stale signal as a plan.

Cost accounting should separate durable requirements from emerging demand. A training decision that changes an occupation's core skill set needs evidence that the requirement is stable across employers and time; a decision that adds an emerging tool can be smaller, reversible, and explicitly time-boxed. The verification numbers above are the minimum cost of being wrong in either direction.

What this evidence does not establish

This section does not re-litigate which source is better in general; it marks the boundary conditions where the one-rule decision fails or must be qualified. The rule still applies to the questions it was built for, but these two cases can make a measured gap look like a source problem rather than a labor-market problem.

Hybrid or renamed occupations are the first break point. If postings are classified to the wrong O*NET code, the apparent skills gap is partly a classification artifact: the comparison is between employer demand for one job and occupational content for another. The rule breaks when roughly more than 20–30 percent of the sample maps ambiguously; below that, the rule still wins if the mapping is clean and the report states the mapped share. In practice, that means publishing the share of postings that could not be assigned confidently, not burying the ambiguity in a single headline gap.

Informal-sector work is the second break point. As the transition figures above show (6.84% informal-to-formal and 6.24% formal-to-informal), a large share of employment movement happens outside formal postings entirely.

O*NET plus postings cannot see that movement, so the rule does not establish anything about informal-sector transitions; use labor-force survey data for that question.

Taken together, these limits are scope limits, not source failures. The rule remains valid for durable occupation-level requirements and emerging employer demand, but only after the mapping share is reported and informal-sector movement is measured with the right data.

Measuring one skills gap

Start with one occupation and one pipeline. Pull the O*NET occupation profile, then sample 200 recent postings for that same occupation. Label every posting on a single chain: extracted skill term → mapped O*NET skill element → importance from 0 to 5. That third column is your judgment call, so write the rubric down before you start scoring, or two analysts will produce two different datasets.

Checkpoint 1 is coverage. Divide the number of extracted skill terms that map to an O*NET element by the total number of extracted terms. If that share falls below roughly 70%, your classification is too noisy to interpret — widen the sample or fix the mapping before you compute anything else. A low coverage number is not a finding about the labor market; it is a finding about your taxonomy.

Checkpoint 2 is the delta. For each O*NET skill element, compute the mean posting importance minus the O*NET rated importance. A positive delta means employers are asking for more of that skill than the occupation profile implies; a negative delta means the profile is carrying weight the postings do not. Rank the deltas and read the top and bottom of the list, not the middle. Deltas near zero are the boring, durable core — that is what you would expect O*NET to get right.

Checkpoint 3 is stability. Re-run the same pipeline on a second sample of postings drawn from a different month or a different source. If a skill element's delta flips sign between samples, treat it as noise, not signal. Only elements that hold their direction across both samples belong in a skills-gap claim.

Audit checklist you can copy: one occupation named; 200 postings sampled and dated; every extracted term mapped or explicitly marked unmapped; coverage share reported; importance rubric written before scoring; deltas computed per O*NET element; second sample run; sign-flip elements discarded; and every O*NET figure traced to the O*NET Resource Center, which updates the database quarterly and publishes an Occupation Update Summary for data currency. If any line is blank, the gap you are about to report is not yet measured.

Worked Example: Run the Numbers

Illustration (not a measured case): a workforce analyst at one employer is deciding, for 2026 planning, whether a skill cluster is a durable requirement of an occupation or current employer-specific demand. The inputs are one occupation, the current O*NET quarterly release, a weekly posting sample running through that same quarter, and the fixed rule: use O*NET for durable occupation-level requirements and transitions, use postings for emerging employer-specific demand, and cross-check any posting-derived skill against the current O*NET profile before treating it as an occupation-level change.

Step 1 sets the observation windows: one standardized O*NET profile per quarter is 4 snapshots per year, while one weekly posting pull is 52 pulls per year. Step 2 compares responsiveness: 52 divided by 4 equals 13 posting pulls for every O*NET snapshot. That ratio illustrates why postings can surface employer demand sooner; it does not show that the demand is occupation-wide.

Step 3 applies the source rule. If the skill appears in the current O*NET profile, classify it as a durable occupation-level requirement and measure gaps against that profile. If it appears only in postings, classify it as emerging employer-specific demand, even if it appears in every weekly pull, because frequency in postings does not convert an employer signal into standardized occupational content.

Step 4 cross-checks before escalation. Compare the posting-only skill with the same occupation's current O*NET profile. If the profile already contains an equivalent skill, the posting is corroboration rather than a new gap. If the profile does not contain it, keep the signal in the employer-demand bucket and schedule a re-check at the next quarterly O*NET release.

Winner for this example: O*NET, because the stated question is durable occupation-level skill requirements. Break-even trigger: postings become the lead source only when the measurement question shifts to emerging, employer-specific demand; if a posting-only skill survives one full quarterly O*NET cycle without entering the standardized profile, re-run the cross-check and, if it is still absent, keep it classified as employer-specific demand rather than an occupation-level change.

Decision rules for 2026

If the question is what an occupation requires durably—for assessment, policy, or transitions—use O*NET and cite the Occupation Update Summary date for the profile used. The citation is the first check: it ties the baseline to a documented occupational record and prevents a market snapshot from being treated as an occupational standard. If the date cannot be cited, the profile is not ready to support a durable-requirements claim.

If the question is what employers are asking for right now—for curriculum refresh or hiring criteria—use job postings and state the sample size per occupation. The sample size is the first check: without it, a posting pattern cannot be distinguished from employer-specific wording, a small employer set, or a temporary requisition spike. State the occupation, sample, and collection window together so the demand signal can be reproduced.

If a postings-derived skill delta exceeds +1.0 O*NET importance points and mapping coverage is above roughly 70%, treat it as a real skills gap and act. If either condition fails, treat the delta as unverified demand, retain O*NET as the baseline, and cross-check the posting signal before changing requirements. The two conditions are conjunctive: magnitude alone is not enough, and coverage alone is not enough.

Apply the source test before choosing data. Durable occupational content belongs to O*NET; current employer demand belongs to postings. The rule set assigns each question to the source that can answer it and does not allow either source to stand in for the other. A curriculum question about durable requirements should not be answered with postings alone, and a hiring question about current demand should not be answered with O*NET alone.

When the sources disagree, let the threshold decide. A posting signal that clears both the magnitude and coverage tests can justify a curriculum or hiring change; a signal that misses either test should be logged for the next refresh cycle rather than treated as an established gap. This keeps one noisy posting cycle from rewriting an occupational baseline.

Document the decision path with the question type, selected source, citation or sample size, and threshold result. That record makes the 2026 skills-gap claim reviewable without reopening the source debate for every occupation and shows which rule was applied.

What to do next

Frequently Asked Questions

How frequently is the O*NET Database refreshed?

The O*NET Database is updated quarterly, according to the O*NET Resource Center.

Where can I verify how current the data is for a specific occupation I'm researching?

The public Occupation Update Summary documents data currency for each occupation.

Which source should I mine for demand tied to a new, niche, or single-employer skill requirement?

The reader rule assigns postings to emerging demand, so job postings cover emerging, employer-specific skill demand — but any posting-based measure must be cross-checked against O*NET occupation content.

Is an O*NET occupation profile a live feed of current market openings?

No — a cited profile is a curated occupation-level record that occupational analysts build by synthesizing survey inputs, rather than a live market feed.

What does the SSA need from occupational data when handling disability claims?

SSA disability claims require medical and, in many cases, occupational information through the OIS Project, whose objective is to evaluate medical and, in many cases, occupational information.

Does the guide give many selection criteria or one rule for choosing between O*NET and job postings?

It sets one rule for choosing the source by question type: postings for emerging demand, cross-checked against O*NET, and O*NET for durable, occupation-level skill requirements.

Quick answers

Also worth reading: The core human skills AI can never truly replace: core human skills AI can · Maximize Operational Efficiency with the Best Compliance Management Software for 2026: Maximize Operational Efficiency with the · Who Gets the Overtime Shift: 2026 Fair Workweek Gap — 24% Audit or Trust: Who Gets the Overtime Shift: