Short answer
A warehouse task taxonomy lists process stages (receiving, put-away, picking, packing, shipping, returns), the task families inside each, and the fields that describe a data request: unit of handling, object class, container, environment and exception type. Using one vocabulary lets buyers and suppliers agree what is being recorded and hold out evaluation data cleanly.
Why a shared vocabulary matters
Warehouse requests tend to arrive as "pick and pack data," which can mean a dozen different things. A supplier hears "pick" and offers case-picking footage; the buyer wanted each-picking of polybags. A taxonomy fixes this by giving each task a name, a handling unit and a set of attributes. It also makes data balance auditable: you can report how many examples fall under each cell and hold out cells for evaluation.
This page offers a working taxonomy and a request specification you can adapt. It is a scoping tool, not an industry standard, and your operation may name stages differently. Occupational task descriptions can help cross-check coverage: O*NET provides task statements and Detailed Work Activities with a mapping between them (O*NET Resource Center), which can help reveal tasks a worker does that your list has missed. It describes human occupations, not robot capability.
Process stages and task families
The stages follow the product flow through a facility. The warehouse literature organizes order picking around layout design, storage assignment, routing, order batching and zoning (de Koster et al., 2007); those are planning topics, and each has physical tasks beneath it.
| Stage | Task families | Typical handling unit | Related page |
|---|---|---|---|
| Inbound | Unload trailer, scan, inspect, sort, label | Case, pallet, parcel | Trailer and container unloading, receiving and inbound checks |
| Storage | Put-away, replenish, cycle count | Case, tote, pallet | Cycle counting |
| Picking | Each pick, case pick, layer pick, goods-to-person pick | Each, case | Each-picking demonstrations |
| Consolidation | Sortation, put wall, singulation, tote handling | Each, tote | Put walls |
| Packing | Box selection, void fill, closing, labeling | Each, carton | Packing demonstrations |
| Outbound | Palletize, wrap, load trailer | Case, pallet | Case picking and mixed palletizing |
| Returns | Receive, inspect, grade, restock | Each | Returns processing workflow |
| Cross-cutting | Exceptions, barcode scanning, equipment handling | Any | Warehouse exception handling |
Which stages dominate depends on the operation type; see e-commerce fulfillment vs B2B distribution.
Illustrative request specification
# Illustrative only - field values are synthetic; set every value to your own needs
request_id: wh_task_spec_v0
task:
stage: picking
family: each_pick
start_state: item in bin_B, order line open
end_state: item in tote_A, pick confirmed
attributes:
handling_unit: each
object_class: [rigid_box, polybag, bottle]
object_weight_class: light
container: {source: shelf_bin_B, destination: tote_A}
environment: {lighting: fluorescent, floor_level: ground, shelf_height_range: mid}
mode: human_demonstration # or robot_log, teleoperation
exception_types: [barcode_unreadable, item_missing, item_damaged]
modalities: [head_video, fixed_video, wms_task_record]
labels: [task_id, step_segments, outcome, sku_family, operator_id]
evaluation_split: hold out one site and one sku_family
Attributes that change what data you need
- Handling unit: each, inner pack, case, layer, tote or pallet. This alone changes grasp type, load, and object variety.
- Object properties: rigidity, surface (glossy, bagged, transparent), weight, and label placement.
- Container and storage type: tote, shelf, flow rack, pallet, pick face.
- Mode of work: standing at a station, walking an aisle, or using equipment, which affects camera placement and body motion.
- Source of the record: human worker video, warehouse-system records, robot logs, or commissioned capture.
- Exception class: label unreadable, wrong item, damaged goods, blocked location.
Not every combination is needed. A buyer should list the cells that matter for the deployment and mark the rest out of scope.
Acceptance checks for a taxonomy-based delivery
- Every clip or record carries a stage, task family and handling unit from the agreed vocabulary.
- A per-cell count report is provided, and no cell the buyer labeled essential is empty.
- Labels are applied by documented rules, with a sample double-checked by a second reviewer.
- Site, operator and object-family identifiers allow held-out splits.
- Exceptions are coded using the agreed exception types.
- Records state what is excluded, such as robot actions and forces.
Limitations of taxonomies
A taxonomy describes categories, not difficulty. Two clips labeled "each pick" can differ greatly in grasp difficulty. It does not tell you how much data a cell needs, which depends on architecture, embodiment and task. It can also hide cross-task dependencies: a failed pick may trigger an exception flow that the taxonomy files elsewhere.
Existing warehouse recordings rarely carry these labels; check a sample. Expect labeling effort or a commissioned recording to apply them. Human worker video and warehouse-system records do not include robot joint states, commanded actions or forces; those need robot-side data, as discussed under existing warehouse robot logs.
Using the taxonomy: an illustrative worked request
In this illustrative example, a buyer wants data for a humanoid that will work an e-commerce pack station. Using the vocabulary above, the buyer writes the request in four steps.
First, select the stage and families: packing, with box selection, item placement, void fill, closing and labeling. Second, choose attributes: handling unit is each and carton, object classes are rigid boxes and polybags, containers are totes and cartons in three sizes. Third, name the exceptions that matter: item does not fit the chosen carton, label printer jam, and damaged item found during packing. Fourth, define the data modes: human worker video from two viewpoints, packing instruction records, and a commissioned set with a head-mounted camera for hand visibility.
The buyer then builds a coverage grid, with object classes on one axis and carton sizes on the other, and marks the cells that must be filled before evaluation. A supplier can answer cell by cell, and gaps are visible at once. Evaluation cells, such as one object class or one carton size, are reserved and kept out of training. These data modes support task understanding, step segmentation and evaluation; training the humanoid's own control policy for the pack station would still need robot, teleoperation or instrumented capture.
Questions to ask suppliers
- Which of these stages and task families does your footage or log data cover?
- Can you provide counts by task family, handling unit and object class?
- Does your system record stage or task identifiers from the warehouse management system?
- How are exceptions recorded and labeled?
- Which areas of the facility can be recorded, and at which heights and angles?
- Do you use a different task vocabulary, and can it be mapped to this one?
- Which tasks involve client-owned inventory whose recording needs client consent?
- Can new recording target a specific empty cell in the taxonomy?
Discuss your requirements
If you have a list of warehouse tasks to cover, describe the stages, handling units and exception types to SourceX. SourceX reviews the requirement and follows up about potential sources among US businesses; a request does not guarantee a match. Start from the warehouse data hub or the humanoid training data guide for the wider map, and see the catalog entry for supply chain and logistics data.
Discuss your humanoid training-data requirements with SourceX
Sources
- Design and control of warehouse order picking: A literature review — planning topics in order picking.
- ONET Database (ONET 29.1 per search snapshot): Task Statements and Detailed Work Activities — task statements and DWA mapping used as a coverage cross-check.