Short answer
Public occupational taxonomies give a buyer a shared vocabulary for scoping a procedure corpus: O*NET lists task statements and detailed work activities per occupation, and the Standard Occupational Classification supplies the occupation hierarchy. They describe what workers do, not how, so they define coverage targets rather than procedure content or robot capability.
The problem a taxonomy solves
A team that wants a procedure corpus for a humanoid program usually begins with a list of jobs it hopes the robot will assist with, written by whoever is in the room. That list is hard to defend. It cannot be checked against the world, suppliers use different words for the same work, and gaps appear only when a procedure fails to match.
A public taxonomy replaces the invented list with an external reference. You can say "the corpus covers these tasks from these occupations" and a supplier, reviewer or auditor can check the claim against a document they can open. This page covers the scoping step. Matching real documents against the scope is the job of procedure coverage mapping.
The two taxonomies
Standard Occupational Classification (SOC). The 2018 SOC has 867 detailed occupations, 459 broad occupations, 98 minor groups and 23 major groups. It was established by the Office of Management and Budget, federal agencies publishing occupational statistics must use it, and each worker is classified into one detailed occupation by the tasks performed (BLS and OMB, 2018). Use it as the outer frame: which occupations are in scope, grouped by family.
O*NET database. O*NET includes Task Statements and Detailed Work Activities (DWAs). A "Tasks to DWAs" file maps each task statement to the DWAs it involves, and task statements are retained only if their relevance rating is 25% or higher (O*NET Resource Center). Use it as the inner frame: within an occupation, which tasks and which generalized activities exist.
The edition changes over time; the version cited here is O*NET 29.1, so confirm the current release and file layout before building on it.
Illustrative scoping workflow
- Pick the occupational families you expect your robot to work beside, using SOC groups, not job titles.
- Within each, list the detailed occupations and download their task statements.
- Map statements to DWAs through the mapping file, so that tasks from different occupations that share an activity collapse into one coverage cell.
- Mark each cell by physical content: hands-on manipulation, navigation, inspection, communication, record-keeping, or judgment.
- Mark the cells that your robot program actually targets, and the ones procedures could plausibly inform.
- Hand the cell list to suppliers as the coverage requirement.
Step 4 is where the taxonomy stops helping. Neither source says which statements involve physical manipulation, which are safe to automate or which a given humanoid can perform. You add those columns yourself.
# Illustrative only - synthetic rows, not O*NET content
cell_id,soc_family,activity_label,physical_content,target_for_robot,procedure_type_sought
C001,family_A,"prepare surfaces for work",manipulation,yes,work instruction
C002,family_A,"record completed tasks",record-keeping,no,none
C003,family_B,"inspect equipment for faults",inspection,maybe,checklist
C004,family_B,"clean work areas",manipulation,yes,SOP with photos
What the taxonomies can support
- A coverage vocabulary that is not invented by the buyer or supplier.
- A way to group diverse documents under the same activity so that a corpus is not counted by volume alone.
- A prioritization input, once you add your own task frequency and value data; see task frequency for prioritizing procedures.
- A shared frame for annotators, since the same activity labels can tag procedures and demonstration clips; compare demonstration coverage planning.
- Language for role-specific searches, as in role-based procedures.
What they cannot support
- Procedures. A task statement is a one-line description of a duty, not steps, tools, parameters or checks. It is a label for a document you still have to find.
- Frequency or importance within your site. The 25% relevance retention rule filters statements for the database; it does not tell you how often a task occurs in a given business.
- Robot capability. A statement can describe work a humanoid cannot do with current hardware. Scoping to a taxonomy is not a feasibility study.
- Granularity. Statements vary in level. One may describe a whole job duty and another a single action, so you may need hierarchical task analysis, a method Stanton's review describes as in use for decades (Stanton, 2006), to normalize them, and step granularity to decide how far to split.
- Physical control. Nothing in a taxonomy contains motion, force or perception data, and procedure text alone cannot train control; see what SOPs can and cannot teach a humanoid.
Using the taxonomies with suppliers
Hand suppliers the cell list instead of the taxonomy itself. A supplier may not know your SOC families, but can tell you whether they hold a procedure for "clean work areas" or "inspect equipment for faults". Ask them to answer per cell with a count of documents, the sites they come from and the document type, and to mark cells they hold only in part. This turns a vague search into a checklist that is easy to compare across suppliers.
Keep the mapping versioned. When O*NET releases a new edition, record which statements changed and whether any cell moved. A taxonomy is a measuring tape, and you need to know which tape you used.
Practical cautions
Occupation boundaries often do not match workplace reality. In a small business one person may perform tasks that the taxonomy assigns to three occupations, and a supplier's procedures are organized by station, equipment or shift, not by SOC code. Expect a many-to-many mapping, and ask suppliers to tag documents with the activity they describe instead of forcing a code.
Check the terms of use of the version you download, and record the release number in your requirement, since a corpus mapped to one release may not map cleanly to the next. This is a documentation question, not a licensing conclusion; a procurement lead should confirm the reuse terms with counsel. This is not legal advice.
Questions to ask suppliers
- Can your procedures be tagged by SOC occupation or by O*NET activity, and who would do the tagging?
- How many distinct activities from our scope list are covered, and how many procedures sit behind each?
- Which activities in our scope list have no document at all in your holdings?
- Are procedures organized by role, station, equipment or product, and can you map that structure to our cells?
- At what granularity are procedures written: whole job, task or step?
- For hands-on activities, are there photos, diagrams or linked recordings, or only text?
- How current are the documents relative to the work as practiced today?
- Which sites or business units do the procedures come from, and how do they differ?
- Can a sample be drawn per coverage cell so we can test the mapping before purchase?
Discuss your requirements
If you have a scope list and need to know whether US businesses hold procedures that match it, describe the activities, formats and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX follows up about potential sources. Start at the humanoid training data guide or the procedures hub, and see the site's catalog entry for SOPs, playbooks and knowledge bases.
Discuss your humanoid training-data requirements with SourceX
Sources
- ONET Database (ONET 29.1 per search snapshot): Task Statements and Detailed Work Activities — task statements, DWAs, the mapping file and retention rule.
- Standard Occupational Classification (2018 SOC) — occupation hierarchy counts and classification by tasks performed.
- Hierarchical task analysis: Developments, applications, and extensions — HTA as a long-used method for decomposing tasks.