Warehouse Exception Handling Data: Short Picks, Damages and Holds

The buyer's problem

A system that handles the happy path is not ready for a warehouse. The test of a deployed robot is what it does when the bin is empty, the item is crushed, the label does not match or the location is locked. In each case the right move may be to stop, flag and ask a person, not to try harder.

Evaluation leads need examples of those moments, with the correct response. Existing records are one of the few places they are written down. Exceptions are rare in any one shift, so a buyer who sources only routine footage can end up with an evaluation set that rarely tests escalation. This page covers sourcing exception records; the closely related pick errors and mispicks page covers outcome labels for incorrect picks, and returns processing workflow covers the reverse flow.

Exception types and where they are recorded

Order picking is described as the most labour-intensive and costly warehouse activity, with its cost estimated at as much as 55% of total warehouse operating expense (de Koster et al., 2007). Exceptions interrupt that flow, which is why sites log them: each one costs time and often requires a supervisor.

What this data can support, and what it cannot

Can support. Building a catalog of exception types and trigger conditions; designing evaluation scenarios in which the expected output is "stop and escalate" or "set aside"; training classifiers for damage and mismatch from photos; analyzing how frequently each exception occurs; and writing escalation rules. Published robotics work on failure shows related ideas. REFLECT summarizes multisensory robot data so that a language model can explain failures and plan corrections, and introduces the RoboFail dataset of failed executions in simulation and the real world (Liu et al., 2023). AHA is an open-source vision-language model for detecting and explaining manipulation failures, using procedurally perturbed simulated demonstrations to generate failures (Duan et al., 2024). Both concern robot failures; warehouse exception records are about human-run operations, so they supply scenarios and labels for what counts as an exception, not robot failure traces.

Cannot support. Records of human handling exceptions do not show how a robot should recover. They contain no robot actions. Exception codes are coarse and entered by people under time pressure, so the code may not reflect the real cause. Photos exist only for some cases. And because the records show the supervisor's resolution, they teach policy rules more than motion. For the distinction, see what SOPs can and cannot teach a humanoid, which applies equally to exception procedures.

Illustrative request package

# Illustrative only - synthetic values
package: warehouse_exceptions_v0
sites: 2 (site_014, site_058)
period: stated date range, covering peak and non-peak
tables:
  exceptions: [exception_id, t_utc, type_code, location_token, unit_token, station_id, resolution_code, resolved_t_utc]
  holds: [hold_id, reason_code, start_t, release_t, quantity_class]
attachments: photos or short clips where captured (share of records with media stated)
code_dictionary: full list of exception and resolution codes with definitions
labels_added: [escalate_expected: yes/no, cause_category, recoverable_by_operator: yes/no]
excluded: [operator_name, customer_data, client_sku_names]
holdout: by site and by time period

Quality and acceptance criteria

• Code dictionary. Without definitions, codes are unusable. Ask for the full list, with change history.
• Media coverage. State the share of exceptions with photos or video, and whether media shows the item, the location or both.
• Resolution recorded. A record with a type but no outcome is a half label.
• Timing. Time from detection to resolution shows escalation cost.
• Mix. Look at how many distinct types appear; a set with only short picks is narrow.
• Rare cases. Ask how unusual events, such as holds for recall, are represented and how many exist.
• Consistency. Compare how two sites code the same event.

Supplier types

Fulfillment centers and 3PLs log exceptions in WMS and inventory-control systems; quality teams keep damage photos; customer service keeps claims. Records often involve client inventory, so read client-owned inventory rights and 3PL providers as warehouse data suppliers. Related procedures and counts are in cycle counting and inventory checks. Documenting what you receive helps; see Datasheets for Datasets, which proposes that every dataset be accompanied by a datasheet covering motivation, composition, collection process and recommended uses (Gebru et al., 2018).

Limitations and additional preparation

Exception data is sparse, unbalanced and tied to one site's codes. It needs a mapping of codes to a shared taxonomy, redaction of client and operator details, and annotation of whether the correct response was to escalate. Photo evidence may show client goods. A test of escalation needs scenarios on the robot's own platform; these records feed scenario design and labels, and the robot behavior itself must come from robot trials. Keep evaluation scenarios separate from anything used for training; see the warehouse pick evaluation protocol.

Turning exception records into evaluation scenarios

An exception log is raw material. To use it for evaluation, a team typically (1) groups codes into a small taxonomy, (2) picks several cases per type, (3) writes down the expected response, such as stop, flag, set aside or re-scan, and (4) builds the scenario on the robot platform with physical props or a staged setup. The records tell you which exceptions occur and how they were resolved; they cannot tell you how a robot will behave.

Two cautions apply. A resolution code written by a supervisor reflects site policy, and another site may resolve the same event differently, so state the policy in the scenario. And exceptions that occur often in records may not be the ones that matter most for safety or cost, so ask the supplier for the rare, severe cases too, even if they number only a handful.

Questions to ask suppliers

1. Which exception types are logged, and can you share the code dictionary?
2. How are codes entered: scan, menu selection or free text?
3. What share of exceptions include photos or video, and of what?
4. Is the resolution recorded, and by whom?
5. How many exceptions of each type occurred in the period, including rare ones?
6. Do exception codes differ between sites or systems?
7. Are holds linked to quality, recall or customer reasons, and are those fields shareable?
8. Whose goods appear in photos, and have clients approved licensing?
9. What identifiers of staff or customers are in the records?

Discuss your requirements

If you can describe the exception types and evidence your evaluation needs, tell SourceX what your evaluation set needs to cover. SourceX reviews the requirement, follows up about potential sources among US businesses, and checks the data and the supplier's licensing permissions. A request does not guarantee a match. See the humanoid training data guide and the warehouse and fulfillment hub; catalog context is on the workflow task histories page.

Tell SourceX what your evaluation set needs to cover

Sources

• Design and control of warehouse order picking: A literature review — order-picking cost share estimate.
• REFLECT: Summarizing Robot Experiences for Failure Explanation and Correction — failure explanation from robot data; RoboFail dataset.
• AHA: A Vision-Language-Model for Detecting and Reasoning Over Failures in Robotic Manipulation — failure detection and reasoning model; procedural failure generation.
• Datasheets for Datasets — dataset documentation proposal.