What Is O*NET and How Does It Work?

Three weeks before the board meeting, someone asks: "which of our roles are exposed?"

A People Analytics Lead at a 900-person logistics company gets the question from the board deck review: their PE sponsor wants a role-level view of AI exposure across the org, not a slide of industry statistics. The World Economic Forum's Future of Jobs Report 2025 projects that 39% of workers' core skills will be transformed or made outdated by 2030 — a useful macro number, but it says nothing about this company's 340 job titles, half of which are internally invented and don't match anything in a public taxonomy.

The honest starting point for that kind of analysis isn't a survey or a consulting deck. It's ONET — the occupational database the US Department of Labor has maintained for decades, and the same database that credible exposure-scoring methods, including WorkforceAnalysis's own rubric, are built on top of. This article explains what ONET actually is, how it's structured, and what it can and can't tell you on its own.

What O*NET actually is

O*NET — the Occupational Information Network — is a free, public database sponsored by the U.S. Department of Labor's Employment and Training Administration (USDOL/ETA). It exists to answer a deceptively hard question: what does a given occupation actually involve, in enough structured detail that software, researchers, and career-counseling tools can use it?

Rather than a job title glossary, O*NET is a taxonomy with data attached. Each occupation carries dozens of structured attributes — the tasks workers perform, the tools and technologies they use, the skills and knowledge those tasks require, and how important and how frequent each task is judged to be by job analysts and incumbent workers. It's the same underlying data source behind the Bureau of Labor Statistics' occupational classification work and behind most serious workforce-planning software on the market.

ONET currently covers 1,016 occupational titles, of which 923 are data-level occupations — meaning they have full descriptor data attached rather than serving only as a title variant — spanning more than 55,000 individual jobs in the US economy (ONET Resource Center, 2019). Each occupation is described by roughly 277 descriptors, and the database is updated on a rolling basis, with the primary annual update typically landing in the third quarter (U.S. DOL, 2025). The specific release referenced in this article is O*NET database v30.3 (O*NET Resource Center, 2025) — always confirm the version your tools are drawing from, since the underlying data does change.

This site incorporates information from ONET. Used under the CC BY 4.0 license. ONET is a trademark of USDOL/ETA.

How O*NET organizes work: SOC codes and occupation hierarchy

ONET occupations sit inside a broader federal classification system called the Standard Occupational Classification (SOC). Under the 2018 SOC structure, the Bureau of Labor Statistics defines 23 major groups, 98 minor groups, 459 broad occupations, and 867 detailed occupations (U.S. BLS). ONET takes those 867 detailed occupations and, where useful, splits them further into more specific ONET-SOC titles — which is how the ONET database arrives at over a thousand occupational titles from a base of 867 SOC detailed occupations.

Every ONET occupation carries an ONET-SOC code, an eight-digit identifier built on the underlying six-digit SOC code plus two digits of O*NET-specific detail. That code is the anchor everything else attaches to: task lists, skill requirements, work activities, and importance ratings are all filed against the code, not the job title.

This distinction matters more than it sounds like it should. A single job title inside a company — "Operations Analyst," say — might map cleanly to one O*NET-SOC code, or it might straddle two or three depending on what the role actually does day to day. Getting that crosswalk right is its own discipline; we cover the practical mechanics of it in how to map job titles to O*NET occupations and in O*NET SOC code lookup by job title.

Inside an O*NET profile: task statements and importance ratings

Once you're looking at the right O*NET-SOC code, the profile underneath it is where the real substance lives. Each occupation carries a list of task statements — plain-English descriptions of specific things workers in that role do. A Human Resources Specialist profile, for example, includes tasks like "interpret and explain human resources policies" and "maintain and update human resources documents."

Each task carries an importance rating, typically collected on a numeric scale from job analysts and incumbent workers, indicating how critical that task is to successful performance of the job overall. This is the detail that separates O*NET from a generic job description: it doesn't just tell you what a role involves, it tells you how much each piece of that role matters relative to the others. A task rated as low-importance but frequently mentioned in job postings is a very different signal than a task rated critical to the role's core function.

Importance ratings are also the input that makes exposure scoring possible rather than just descriptive. If you're going to say a role is more or less exposed to automation, you need to weight the tasks that matter most to the job, not just count how many of its tasks look automatable. We go deeper into the ratings scale itself, including how it's collected and its documented limitations, in O*NET task importance ratings explained.

Alongside tasks, O*NET also catalogs generalized work activities — broader categories of activity (e.g., "getting information," "analyzing data or information," "interacting with computers") that sit one level up from individual task statements and let you compare very different occupations on common ground. The full catalog is covered in the O*NET work activities list guide.

From O*NET data to an exposure score: a worked example

Here's a simplified, illustrative walkthrough of how task-level O*NET data feeds an exposure score — using round example numbers, not a real occupation's actual output.

Suppose a role has three ONET task statements, each carrying an importance weight (on a 0–1 normalized scale, derived from ONET's importance ratings) and a score on each of four exposure dimensions — cognitive routine, physical routine, social/judgment, and creative, each scored 0–100:

The role's weighted cognitive-routine score, for example, works out to (0.5 × 80) + (0.3 × 60) + (0.2 × 30) = 40 + 18 + 6 = 64. Run the same weighted calculation across all four dimensions and you get a task-importance-weighted exposure profile for the role, rather than a flat average that would let a minor, rarely-performed task distort the score.

That profile is an input, not a verdict. A role landing at 64 on cognitive routine and low elsewhere isn't "safe" and isn't "automatable" — it's a data point that tells a reviewer where to look. In WorkforceAnalysis's own workflow, roles land in one of three review states — Monitor, Review, or Redeployment Candidate — precisely because a score is a starting point for a human conversation, not a conclusion.

Where O*NET stops and judgment has to start

ONET is descriptive, not predictive. It tells you what a role involves today and how important each part is judged to be — it does not tell you what will happen to that role as AI tools mature, and it was never designed to. That gap is exactly where exposure methodology has to add a layer: mapping company-specific job titles onto ONET occupations, applying a consistent scoring rubric across the four dimensions, and rolling task-level scores up to a role or department view a leadership team can actually act on.

It's also worth being honest about ONET's blind spots. Task statements describe the job as documented at a point in time; they lag genuine role evolution, and two companies with the same job title can staff it very differently in practice. That's why a credible exposure process treats the ONET mapping as a starting hypothesis to be checked against how the role actually functions inside a specific company — not as a database lookup you can run unattended.

Getting the O*NET mapping right the first time

Most of the analytical error in company-level exposure work doesn't come from the scoring rubric — it comes from a sloppy title-to-occupation crosswalk upstream of it. A generic title like "Manager" or "Coordinator" can map to a dozen different O*NET-SOC codes depending on what the role does, and getting that step wrong quietly corrupts everything downstream.

If you're building this mapping manually, plan for it to take real analyst time per role, and expect edge cases — internally invented titles, blended roles, titles that mean different things in different departments — that a lookup table alone won't resolve. For a fuller walkthrough of company-specific exposure work end to end, including where O*NET mapping fits into the larger process, see our guide to company-specific AI workforce exposure.

If you want the fuller, citation-backed version of this methodology — including the full task-importance rating scale, the work-activities taxonomy, and a step-by-step mapping workflow — the O*NET Task-Mapping Methodology Handbook walks through all of it in depth.

And if you'd rather have methodology explainers like this one land in your inbox as we publish them — no product pitch, just the O*NET and exposure-scoring mechanics — subscribe to our newsletter from the blog.