Barcode Scanning Workflows

The deployment problem

Almost every warehouse handling step ends in a scan or begins with one. Receiving scans a case, picking scans an item or location, packing scans to verify, shipping scans a parcel onto a manifest. A robot working in that flow must present items to a scanner, read labels itself, or hand off to a scan point, and it must respect the scan sequence the system expects.

For buyers, the scan is attractive for a second reason: it is a machine-written label. A scan stamps the moment a person completed a step, identifies the unit, and sometimes confirms location. If the events are aligned with video, a large volume of footage can be segmented and labeled without annotators. The page on pick confirmation as automatic labels develops that idea; this page focuses on the scanning task itself.

Task anatomy

Logistic labels follow standards. The GS1 Serial Shipping Container Code is an 18-digit key identifying a logistic unit such as a case, pallet or parcel, commonly encoded in GS1-128 on the GS1 Logistic Label or in EPC/RFID, and it keys ASN or despatch advice data (GS1). A scan of an SSCC can therefore tie a video interval to an advance shipping record, which is a richer label than a bare product code.

What this data can support, and what it cannot

Can support. Step segmentation of scan-based workflows, activity recognition around a scanner, label-presentation analysis (how often the label faces the reader), cycle-time statistics, no-read detection, and checking whether a task sequence matches the expected one. Label and barcode localization in images is a perception task that scan-adjacent video can also feed.

Cannot support. A scan event is a discrete timestamp, not a motion. It tells you a step ended, not how the hand moved, and it does not capture what happened between scans. Video from a handheld-scanner operator does not give a robot its actions; see what human demonstration video can and cannot do and the embodiment gap. A scan also does not prove that the right item was physically handled; a person can scan one item and place another. For outcome checking, see pick errors and mispicks.

Capture and labels

Existing assets include scan logs from RF guns, wearable scanners and fixed tunnels, station cameras and, in some sites, body or head-mounted video. Candidates for labels derived from scans:

• step boundary at each scan timestamp;
• unit identifier (hashed or tokenized by the supplier where required);
• location or container identifier at scan;
• scan device and read result (read, no-read, manual entry);
• order or task identifier, so steps can be grouped;
• exception flags and reason codes.

Video-derived labels a buyer may add: label-facing-reader flag, hand visibility, label type (shipping label, case label, item barcode), and angle of presentation.

Illustrative alignment record

# Illustrative only - synthetic values
task_id: task_77231
site_id: site_012
video:
  file: station_08_2026-02-03T10-00.mp4
  clock: ntp, offset_ms_logged: true
scan_events:
  - {t_utc: 2026-02-03T10:14:22.480Z, device: handheld_14, code_type: logistic_unit, result: read, unit_token: u_5f31}
  - {t_utc: 2026-02-03T10:14:41.010Z, device: handheld_14, code_type: item, result: no_read}
  - {t_utc: 2026-02-03T10:14:43.600Z, device: handheld_14, code_type: item, result: read}
derived_labels: [step_start, step_end, rescan_flag]
excluded: [operator_name, customer_address, robot_state]
check: median offset between scan stamp and visible scan in video <= buyer-set tolerance

Quality and acceptance criteria

• Offset test. Sample scans across shifts and measure the gap between the system timestamp and the visible scan moment in video. The tolerance is the buyer's to set, but it must be tested, not assumed.
• Join coverage. Report the share of scan events that join to a video interval and the share of video minutes with no scan.
• Read-result mix. A set with only clean reads will not teach no-read handling.
• Device variety. Handhelds, ring scanners, tunnels and fixed readers produce different footage and different timing.
• Label type variety. Case labels, item barcodes and parcel labels.
• Held-out sets. Hold out by site and device type.

Supplier types

Fulfillment centers and 3PLs generate scan data in volume, and WMS vendors store it. Footage depends on the site's cameras. Scan logs often contain operator IDs and client SKUs. For supplier context see 3PL providers as warehouse data suppliers and client-owned inventory rights. For tasks that begin at the dock, see receiving and inbound checks.

Limitations and additional preparation

Scan data is outcome data. It needs time alignment, a join key and decisions about identifiers before it labels anything. Video may not show the scan itself if the scanner is outside the frame. Logs may be tokenized or truncated for privacy. Manual keying hides what happened. A robot that scans needs its own sensor, camera and presentation motion, which only robot data can provide. Mixing scan-derived labels into evaluation without human spot checks risks measuring the label rather than the task.

Reading the scan log critically

A scan log is easy to read and easy to over-trust. Four patterns deserve a look in any sample. First, runs of scans separated by very short gaps can indicate batch scanning of labels at a desk, not scans at the point of handling. Second, scans clustered at shift start or end can be catch-up entries. Third, a high share of manual keying suggests the device or the labels fail often, which is useful material for a model but distorts timing. Fourth, a mismatch between scan device clock and station camera clock tends to drift; check at both ends of a day.

If these patterns appear, the data may still be valuable, but step labels derived from the scans need a confidence tier. The same idea is developed for pick outcomes in pick confirmation as automatic labels, and the video side is covered for pack benches in pack station camera recordings.

Questions to ask suppliers

1. Which scanning devices are used, and in what proportions?
2. Are scan logs available at event level with millisecond or second timestamps?
3. How is the scanner clock synchronized with cameras?
4. Do logs include no-reads, re-scans and manual entries?
5. Which identifiers are present: logistic unit key, SKU, location, order, operator?
6. Can identifiers be tokenized consistently across files?
7. Does any footage show the scan itself?
8. Which customers' codes appear, and has each agreed to licensing?
9. What notice applied to operators whose IDs and faces appear?

Permissions and provenance

Scan records can reveal operators, clients, orders and recipients. Ask who owns each field and whether the supplier can license it; see worker consent and identifiable people. Tokenizing identifiers does not settle who may license the data. This is not legal advice.

Discuss your requirements

If you know which scan devices, label types and event fields your model needs, describe the requirement to SourceX. SourceX reviews it, follows up about potential sources among US businesses, and checks the data and licensing permissions. A request does not guarantee a match. Start at the humanoid training data guide or the warehouse data hub, and see sensor and IoT data for catalog context.

Discuss your humanoid training-data requirements with SourceX

Sources

• Serial Shipping Container Code (SSCC) — logistic unit key, label encoding and link to despatch data.