What O*NET 31.0 Says About Missing AI Duties

What is O*NET 31.0's Emerging Tasks file actually recording?

The O*NET 31.0 Emerging Tasks file records proposed new or revised task statements linked to occupations for possible future data collection. Its 338 rows are a specific update list, not the complete task inventory, a survey of current AI use, or a measure of exposure. The data dictionary describes analysts developing statements from sources that include feedback from surveyed job incumbents, research into emerging technologies, and information from professional associations. A row is therefore a candidate description for further occupational data work, not a verdict about how common a duty is today. Read the columns as identifiers and history. Each entry names an O*NET-SOC code and title, gives proposed task wording, and marks it “New” or “Revision.” A revision may include an original task ID and earlier task wording, showing which published statement the proposed language relates to. The file also records an update date and a domain source. These fields help identify the occupation and statement, whether new wording or a revision is proposed, and the source type. They do not rank a task’s importance or indicate the scale of change. “Revision” means wording change is proposed; it is not a severity label. The O*NET 31.0 Database page puts the row count in context. It lists Emerging Tasks updates for 49 occupations, while the separate Task Statements file contains 18,838 rows. The first number describes occupations with updates in this file; the second describes a different file of occupation-associated task statements. Neither estimates how many workers use AI, how often a duty occurs across employers, or whether an occupation is being displaced. These counts describe database structure and coverage in this release, not labor-market prevalence. Start by identifying the file and its purpose. Emerging Tasks is where proposed additions or revisions appear for future collection. A matching row shows that a candidate statement is recorded for the specified occupation in this release. If a duty does not match, the file alone cannot tell you why. The next useful question is whether the underlying activity already appears in the full task statements, or whether your local workflow contains a distinct recurring duty. Keep those questions separate: a proposed standardized update and work happening in one role are different kinds of records.

Sources: Emerging Tasks - O*NET 31.0 Data Dictionary; O*NET 31.0 Database

If my AI duty is missing, what can I conclude—and what remains unknown?

If your AI duty does not appear in O*NET 31.0's Emerging Tasks file, the narrow conclusion is that you did not find a matching proposed task statement for the occupation code and wording you checked. That is a statement about a particular file and search, not a verdict about your work. The file’s data dictionary describes its entries as new or revised task statements proposed for future data collection. It does not describe the file as a complete inventory of every duty currently performed in every workplace. So an absent match cannot establish that your duty is imaginary, unimportant, unsupported, or unlikely to affect your role. The distinction matters because several different questions can hide inside the phrase “my task is missing.” First, is the activity absent from this candidate-update list, or is it absent from your actual workflow? O*NET’s list can speak to the first. Your repeated work records and the people responsible for the workflow are better evidence about the second. A database description is standardized across an occupation; a local duty can be shaped by a particular employer’s process, customer, regulation, or division of responsibilities. Second, is the underlying activity missing, or is only the AI method missing? A profile might describe preparing a summary, reviewing information, or communicating a result without naming the software used to help with that task. If the wording seems close, that may indicate that the work activity is represented at a broader level even though its current method is not. These are possibilities to check, not known explanations for a particular omission. Third, did the search use the right occupation and the right language? A job title at one organization may not map neatly to one O*NET-SOC occupation. The duty may be described with a synonym, a broader action, or a specialized term that does not match the phrase in the file. A different occupation code could also be the better comparison for a mixed role. Check the code and try wording based on the action and result before treating the search as a non-match. Finally, a proposed statement is not a measurement of how often a task occurs, how important it is in your job, how widely employers use AI for it, or whether employment will change. The O*NET 31.0 Database release page lists Emerging Tasks separately from the much larger Task Statements file. Those counts describe the database’s files, not the prevalence of a duty or the rate of adoption in workplaces. A matching row signals a proposed profile statement; neither its presence nor absence supplies an individual job-loss probability. Keep your own observation and the O*NET comparison side by side. Write down the task in plain language and note where the AI contributes; then record what remains for a person to check or decide. This preserves a specific account without turning one instance into a market-wide finding. The useful question is not “Does O*NET certify that my duty is real?” It is “What exactly did I search, which part of the workflow does the profile describe, and what evidence would show that this change is recurring?” The missing row leaves the local question open.

Sources: Emerging Tasks - O*NET 31.0 Data Dictionary; O*NET 31.0 Database

Why can a curated update process still leave your duty out?

A candidate update list can be methodical and still be incomplete for any one worker. The distinction is between a process designed to identify and develop possible occupational task updates and a live inventory of every workflow now used by every team. The O*NET technical-report summary, “Identification of Emerging Tasks in the O*NET System: A Revised Approach,” says task suggestions can come from job incumbents or occupational experts. Analysts use those suggestions to decide whether new tasks should be added. Once a new task is developed, the program includes it in future data collection to gather information about relevance, importance, and frequency from incumbents and experts. That process is a meaningful counterpoint to the idea that an Emerging Tasks entry is arbitrary. O*NET says analysts draw on feedback from surveyed job incumbents, research into emerging technologies, and information from professional associations. The technical-report summary also identifies process improvements, including natural-language-processing methods used to automate certain review steps. These details support treating a listed row as a considered candidate for an occupation-profile update. They do not show that every source of new work was captured, that every proposed task has become routine, or that all workers in the occupation perform it. Nor do they establish why a particular duty is absent. It would go beyond that evidence to assign a cause to your missing match. The 31.0 data dictionary makes the file’s limited role explicit: its statements are proposed for future data collection. It records an occupation code and title, task wording, whether the entry is “New” or a “Revision,” an optional link to an original task, an update date, and a domain source. Those fields let a reader inspect what a candidate statement says and, for a revision, what earlier task it references. They do not turn the list into a prevalence count. A row’s presence is not evidence that the task is common across employers, and its absence is not evidence that a duty does not exist in a particular workplace. The O*NET description identifies several inputs to statement development, but it does not say that every suggested duty must appear in the same release or under the words a worker would use. The careful conclusion is therefore narrower than either dismissal or alarm. If your AI-related duty is missing, you have learned that this proposed-update file does not show a matching statement under the occupation and wording you checked. The process gives you a reason to take a match seriously as a possible profile-development signal, but not to read it as a census of current work. Conversely, a non-match cannot settle what your own job now requires. You do not need to decide whether O*NET has “missed AI” in general before acting on a recurring change. Carry the concrete duty into the next check: identify its action and output, then compare those with the published task statements. That comparison can reveal whether the underlying work is already described even when its newer method is not. Keep the local observation and the standardized profile side by side; the gap between them is a question to investigate, not a verdict about the worker or the occupation.

Sources: Identification of Emerging Tasks in the O*NET System: A Revised Approach; Emerging Tasks - O*NET 31.0 Data Dictionary

How do I check whether O*NET already describes the work?

Confirm the O*NET-SOC occupation code, then search the complete Task Statements file by the work's action and result, including supplemental statements. An underlying duty may already be represented at a broader level even when the profile does not name the AI method now used to perform it. Treat this as a comparison of descriptions, not a test of whether your employer's workflow is real. Start with the work, not only your internal title. In O*NET 31.0's Task Statements data dictionary, each task statement is tied to one O*NET-SOC occupation code. That makes the code important: a keyword match under another occupation may reveal related work, but does not by itself change the classification of your position. Next, write the duty as a plain verb-and-object description. Ask what action is performed and what is acted on or produced. Search terms such as “summarize customer records,” “draft reports,” or “review claims” may surface broader task language where searching only for a particular AI product or “generative AI” does not. Compare the task's purpose and output, not just the tool name. If AI creates a first draft of an existing deliverable, the profile might describe preparing or reviewing that deliverable without specifying how the draft was produced. A wording match therefore suggests the underlying activity is represented; it does not show that the profile captures the new workflow, its review burden, or who is accountable for its result. Check both categories in the file. The O*NET 31.0 Task Statements dictionary defines “core” tasks using relevance and importance criteria; “supplemental” tasks include statements with lower relevance or importance under its stated thresholds. Supplemental is a classification within the occupation profile, not a signal that the activity is irrelevant to your particular role. Search results should therefore include both categories before you call a duty missing. Leave those ratings for the next comparison: here, the question is whether a related activity appears in the wording at all. Then return to Emerging Tasks. Its 31.0 dictionary includes an optional Original Task ID and Original Task for a “Revision.” If the row is a revision, follow that reference into Task Statements and compare the proposed wording with the existing statement. This can clarify whether the candidate update refines an activity already described or introduces a new one. It still does not establish how widespread the revised wording is or whether a particular employer uses the process. For a “New” row, record its task wording and occupation code as a candidate update, then look for a broader existing statement before concluding that the activity is wholly absent. If your work combines specialties or none of the task lists seems close, O*NET OnLine's Job Duties Custom List offers a navigation aid. Its help page says to select the occupation most like your current work, review its tasks, select duties, and search for occupations with related tasks. Similar tasks are a reason to compare descriptions; they do not establish similar pay, entry requirements, labor demand, or personal fit. Finish with a short discrepancy note: occupation code checked; action and output searched; core and supplemental statements reviewed; any related statement or revision ID found; and the precise part still missing. For example, the activity may appear while the AI-assisted method, verification step, or responsibility for approving the output remains undescribed. That is a more useful finding than “O*NET has no AI duty.” A match shows that O*NET already describes some underlying work, not that it describes your exact workflow. A non-match after this broader search identifies a clearer gap to raise in a local work conversation; it does not explain why the row is absent.

Sources: Task Statements - O*NET 31.0 Data Dictionary; Emerging Tasks - O*NET 31.0 Data Dictionary; O*NET OnLine Help: Job Duties Custom List

What can task ratings add—and what can they not tell me?

Where ratings exist, they add standardized estimates of a task's relevance, importance, or frequency for an occupation. They do not show whether your employer uses AI for that task or how much your own work has changed. In O*NET 31.0, Task Statements give occupation-linked wording; Task Ratings attach measures to some task-occupation pairs. Together they clarify how O*NET classifies a duty, but neither file records your team’s live workflow.

The Task Statements dictionary lists 18,838 occupation-specific task rows and labels tasks core or supplemental. Core tasks meet both a relevance rating of at least 67 percent and a mean importance rating of at least 3.0. Supplemental tasks include duties that meet the relevance threshold but fall below the importance threshold, and duties below the relevance threshold regardless of importance. “Supplemental” therefore does not mean imaginary, optional in every workplace, or irrelevant to a particular worker; it describes how a task meets O*NET’s criteria.

Task Ratings add measures where available. The 31.0 dictionary reports 165,780 rating rows covering 911 occupations, using three scales. Fields include task, scale name, rating value and, where applicable, sample size, standard error, confidence interval bounds, and a low-precision indicator. The file says ratings describe task importance, relevance, and frequency. These fields help readers identify what kind of rating is attached. The dictionary says ratings are available for 911 occupations, so do not assume every duty or specialized role has an equally complete record.

Consider a profile that describes preparing a report, while a worker’s process now includes using a tool to draft part of it and checking the result. A broad statement may describe the underlying work without naming the method. A rating attached to that statement concerns the standardized task as represented in O*NET; it does not isolate the AI-assisted step, measure how often it occurs at this employer, or show the verification burden. This describes the file’s scope, not a particular workplace.

A relevance, importance, or frequency measure cannot be converted into an AI capability or job-risk verdict. A frequent task is not therefore automated; an important task is not necessarily protected from change; a supplemental task does not show that an employer can remove it. The ratings dictionary documents measures and statistical fields for occupation-specific tasks. It does not report whether an employer adopted a tool, whether the tool completes work reliably, whether duties were redistributed, or whether employment changed. Those questions need separate evidence about local workflows and labor outcomes.

Use ratings as context for the standardized profile: they can help explain why a task is classified as core or supplemental and show which measures are available. Separately record what changed in your work, how often the step recurs, what a person verifies, and who remains responsible for the result. No matching rating limits the comparison; it does not erase your observation. A rating still cannot substitute for that observation. O*NET ratings describe tasks in an occupational framework; local evidence is needed to judge their role in your actual workflow.

Sources: Task Statements - O*NET 31.0 Data Dictionary; Task Ratings - O*NET 31.0 Data Dictionary

Why does a task record not settle adoption or displacement?

A profile update describes occupational information; it does not measure current AI use by your employer, whether a tool performs the task reliably, whether work is redesigned, or whether employment rises or falls. O*NET 31.0 keeps kinds of task information in separate files: the release page lists Task Statements, Task Ratings, and Emerging Tasks as distinct data sets. Its Emerging Tasks file contains new or revised statements proposed for future collection. That structure identifies occupational information being considered; it is not a workplace adoption survey or a labor-market outcome measure.

These are different questions. Technical capability asks whether a system can produce an output under specified conditions. Observed use asks whether someone has used it for that task. Employer adoption asks whether an organization has incorporated the tool into a recurring process. Task exposure describes a possible point of contact between technology and work; it does not show that a task is automated. Workflow redesign asks how duties, review, and accountability have changed. Labor demand concerns how much labor employers seek. Displacement concerns whether workers or jobs are reduced as a result. Evidence for one link does not establish the next.

For example, a tool may generate a plausible first draft of a report. That demonstrates a capability in a particular context, not that a team has adopted it. A worker experimenting with the draft is observed use, not necessarily an employer-wide process. After adoption, a person may still gather inputs, check sources, correct errors, handle exceptions, and approve the report. The task is exposed to assistance, but the work change depends on how those steps are arranged. Whether this changes staffing or labor demand is another question. An occupational file does not record that chain for a workplace.

The U.S. Bureau of Labor Statistics report, Assessing the Impact of New Technologies on the Labor Market: Key Constructs, Gaps, and Data Collection Strategies for the Bureau of Labor Statistics, provides broader measurement context. It reviews research and data collection questions; it is not an audit of O*NET 31.0 or a current survey of this reader’s workplace. Its discussion explains that automation can produce both productivity effects, where work becomes more efficient, and displacement effects, where technology substitutes for labor. Net labor effects depend on how these forces combine and vary across applications. The report also describes gaps in data needed to assess technology’s effects. This supports caution about inferring employment outcomes from a task description; it does not tell us which outcome will occur in a given job.

That distinction cuts both ways. A missing Emerging Tasks match is weak evidence about whether a duty exists in your job, but it does not make a recurring local change inconsequential. A matching row is useful as a proposed occupational-information update, but does not establish employer use, reliability, or staffing changes. A task rating can describe occupation-level relevance, importance, or frequency where available, but is not a live measure of AI use at work. O*NET’s release page reports ongoing updates across multiple data categories. It is too broad to dismiss the resource as simply stale; equally, one release cannot describe every local implementation.

Use O*NET to identify and compare a standardized task, then use local evidence to understand your work. If the duty recurs, note what enters the process, what the system contributes, what a person verifies, what the output is, and who remains accountable. Ask a manager or occupational contact what changed, which checks are required, and who owns the decision. If the change is isolated, monitoring may be enough. If it becomes routine and shifts the work or review burden, consider a focused practice project or learning step. A larger move needs more evidence than a missing row: identify the skill gap and compare options against salary, location, time, health, and family responsibilities. The file is a prompt for investigation, not a verdict about your job’s future.

Sources: Assessing the Impact of New Technologies on the Labor Market: Key Constructs, Gaps, and Data Collection Strategies for the Bureau of Labor Statistics; O*NET 31.0 Database; Emerging Tasks - O*NET 31.0 Data Dictionary

What should I record before deciding whether to act?

Record the work as a sequence, not as a label such as “uses AI.” For a recurring duty, note what information or request enters, which step the tool performs, what a person checks or changes, what deliverable leaves the process, how often the step occurs, and who remains accountable for the result. This makes the local workflow legible even when the occupation profile names only the broader activity. Consider an example: a worker is asked to use a system to draft a customer case summary from notes and prior correspondence. The record should separate the input from the output: which notes are supplied, whether sensitive details are removed or approved for use, what the system drafts, and where that draft goes. Then record the human steps: checking names, dates, and commitments against the source; correcting missing context; handling exceptions; deciding whether the summary is appropriate to share; and approving the final communication. The distinction matters: “the tool drafted a summary” describes a capability in that instance, not reliability, team-wide adoption, or transfer of the whole responsibility. A first draft may save composing time while source review, judgment, exception handling, privacy checks, and responsibility remain with a worker. If a routine process changes who performs checks or how much review is required, record that too, even if the broad occupation wording is unchanged. Describe the division of work, not just the tool’s contribution. Write the starting material and result in plain language, then mark each handoff. “Read incoming correspondence and prepare a response” might remain the broad activity; the local sequence could now include an automatically prepared draft, a comparison with the original message, a policy check, edits for a nonstandard request, and a final approval.Separate observed actions from assumptions about what happened behind an interface. If you cannot tell whether the system used a source, mark it unknown and ask the process owner. Do not treat a guessed capability as a completed task or assume a polished output was checked. Add recurrence and review burden.A trial, optional aid, and standard team step are different observations.Note the period, how often it appears in your work, whether use is optional or expected, and what review remains.A personal log cannot establish what an occupation or company broadly does. Repeated examples show whether the task changes in your setting, not adoption elsewhere.O*NET Task Ratings describe relevance, importance, and frequency for covered tasks; your notes describe one workflow. Neither replaces the other. O*NET’s ratings help frame the question. In release 31.0, its Task Ratings dictionary says ratings are available for 911 occupations and includes task-linked rating values, sample information, and precision fields.They characterize standardized tasks, not an individual worker’s AI use.A matching task’s frequency or importance rating is occupation-level context. Do not read it as the frequency of AI use, the amount of time your employer saves, or evidence that a job will disappear.Dated examples answer the narrower question: what is happening in your workflow? Use the note to identify the change before responding. If the tool produces a draft but review still takes careful source comparison, the immediate skill question may be how to verify outputs efficiently and document corrections. If the task is occasional, a dated note may be enough. If it recurs, track a few examples with the same fields. If it becomes routine, bring the pattern to a manager or occupational contact and clarify responsibility, expected review, and whether the workflow is changing formally.This is monitoring, not a labor-demand forecast. Consider training or a career move only after the record shows a specific gap.A bounded project may help with a specific gap such as checking summaries against sources or handling structured information.A short course can teach that skill if its time and cost fit, but it does not automatically qualify you for a new occupation. A larger adjacent move needs a separate comparison of prerequisites, likely pay floor, location, training time, health, and family responsibilities.The Bureau of Labor Statistics’ Assessing the Impact of New Technologies on the Labor Market discusses measurement difficulties and how technology may complement or replace labor inputs.That context supports specific local evidence; one example cannot establish either outcome. A short table or private note can capture date and task; input; tool contribution; human verification or edits; output; recurrence; unresolved error or exception; and accountable person or role. Keep confidential information out of notes unless approved; describing a task rarely requires copying case data.After comparable instances, summarize without overstating: “This step now produces a draft; I check facts and exceptions before approval; it has recurred in these work cycles.” Bring that description to a conversation about standards and ownership.

Sources: Task Statements - O*NET 31.0 Data Dictionary; Task Ratings - O*NET 31.0 Data Dictionary; Assessing the Impact of New Technologies on the Labor Market: Key Constructs, Gaps, and Data Collection Strategies for the Bureau of Labor Statistics

What is the next proportionate move?

Bring one recurring duty to a manager or occupational contact with what happens before and after the AI step, what a person checks, and who is accountable. Ask: “Has this become a regular part of the role, what quality standard should I use to verify it, and who owns the final decision?” That conversation can clarify whether the work is a trial or an established workflow. It gives you language to compare with O*NET task statements. The O*NET 31.0 Emerging Tasks file describes proposed statements for future data collection; a missing match there does not decide whether your local duty is real or consequential. If the change is isolated, keep a note and revisit it. If it recurs, track examples and identify whether you need a focused practice project or learning step. Consider a larger move only when repeated work points to a genuine skill gap, then compare options against your salary floor, location, available training time, health, and family responsibilities. A tool can organize the comparison, but it cannot turn a task signal into a personal job-loss probability. The free task-level checker at /ai-job-risk-checker offers a way to structure that review. If you want scenarios compared with your constraints, the paid roadmap at /career-roadmap is another option; neither guarantees work or income.

Sources: Emerging Tasks - O*NET 31.0 Data Dictionary; Task Statements - O*NET 31.0 Data Dictionary

Questions readers ask