Short answer
To audit product master data before robot use, test each attribute against physical reality: sample items, measure them, and compare against the record. Check units, packaging level, duplicates, stale SKUs, image-to-record linkage and provenance. Catalog data is often wrong in ways that matter physically, such as a case dimension recorded as the each dimension, so pass/fail thresholds should be set per attribute and per intended use.
Why catalogs fail in ways that matter physically
A product master record exists to serve ordering, pricing, shipping and compliance. Nobody checks it for what a perception or grasp-planning stack will do with it, so errors that are harmless to a billing system become physical errors in a robot. A 12-pack record that carries the single-bottle height, a weight entered in pounds into a kilogram field, or an image of last year's packaging will each pass a database constraint and fail at the shelf.
This page is the audit step that sits between "a retailer or brand says it has catalog data" and licensing it for training or evaluation. It assumes you have read product catalog data for robot perception and know why attribute and image data support recognition, not handling. The audit is about whether the records are trustworthy for the narrow uses they can serve. Wider context is in the objects cluster and the humanoid data section.
What a clean master record can and cannot support
Clean records can support object recognition, attribute grounding, language grounding and the construction of evaluation sets that check whether a model identifies the right item. They can support rough feasibility screens, such as whether a product fits a tote.
They cannot show how an item deforms, slips, rattles or leaks when handled, and they say nothing about in-situ appearance under warehouse or shelf lighting. They also cannot substitute for measured physical properties. See object recognition data versus manipulation training data for the full distinction.
Know the reference standard before you audit
Retail and trade data is usually exchanged through standards-based data pools. GS1 publishes a package and product measurement standard covering nominal measurement attributes for retail and non-retail products from the consumer unit up to the pallet; release 3.3 was ratified in August 2026 and replaced the earlier GDSN Package Measurement Rules (GS1, 2026). GDSN lets trading partners share product master data through certified data pools and a global registry, so a supplier's record may have been validated against that structure, or it may be an internal export that was never validated at all.
The word "nominal" matters. A nominal dimension is the declared value for a product type, not a measurement of the unit on your bench. Your audit tests how far reality drifts from the declaration.
For the general quality vocabulary, ISO/IEC 5259-1:2024 provides an overview and framework for assessing and improving data quality across the data life cycle, and the series also covers quality measures and management (ISO/IEC, 2024). Use it to name your dimensions (accuracy, completeness, consistency, uniqueness, currency) so supplier and buyer mean the same thing.
Illustrative audit checklist
Run the checks on a stratified sample of records, not the head of the file. Each row gives a test, a pass condition written as an example the buyer sets, and the evidence to request.
| Check | Example pass condition | Evidence to request |
|---|---|---|
| Unit consistency | Every length, weight and volume field has an explicit unit; no field mixes units | Schema with unit per field; count of null-unit rows |
| Packaging level | Each record states whether it describes the each, inner pack, case or pallet | Hierarchy table linking each to case to pallet |
| Measured dimensions | On a physical sample, 95% of items fall within a tolerance you choose (for example 5 mm) of the record | Bench measurement log with item IDs |
| Orientation convention | Height, width and depth follow a stated rule | Definition document; a diagram per package type |
| Weight reality | Measured weight within a chosen percentage of record; fill variation noted | Scale readings, sample size |
| Duplicates | Duplicate rate below your threshold after normalizing brand, size and pack count | Dedupe method and counts |
| Staleness | Share of discontinued or replaced SKUs flagged and dated | Status field, last-modified date |
| Image linkage | Each image maps to exactly one record, with view and capture date | Image manifest with IDs |
| Image currency | Image shows the current packaging variant | Spot check of 50 records against shelf photos |
| Provenance | Each field has a source: brand-supplied, retailer-entered, scraped | Field-level source column |
Thresholds above are placeholders. A grasp-planning feasibility screen tolerates looser dimensions than a packing-density model, and the right numbers depend on your architecture and task.
Sampling and measurement protocol
Draw the sample by category, packaging type and record age, because errors cluster. Soft goods, multipacks, promotional bundles and items sold in variable fills are the usual offenders. Weigh and measure items yourself or through an independent party, and log the instrument, the operator and the date.
Record each discrepancy by type: unit error, wrong packaging level, transposed axes, rounded value, stale value, or genuine manufacturing variation. The mix of error types tells you whether a cleaning pass can fix the file or whether the source process is unreliable. A file whose errors are mostly unit mix-ups can be normalized. A file whose errors are scattered across fields suggests manual entry with no validation.
Attribute-level traps worth a dedicated test
- Each versus case. Case-level dimensions are frequently inherited by each-level records during migrations.
- Rounded or placeholder values. Strings of identical values such as the same height across hundreds of unrelated SKUs indicate defaults.
- Variable products. Produce, bagged goods and apparel have no single true dimension; check whether the record gives a range or a nominal.
- Packaging redesigns. Barcodes often persist across redesigns while dimensions and artwork change. A record can be correct for the old pack and wrong for the new one.
- Free-text descriptions. Descriptions copied from marketing may contain claims ("fits any shelf") that no field validates. Treat them as text for language grounding, not as measurements.
- Images. A studio packshot on a white background can be the right product at the wrong angle or the wrong variant. See packshots versus in-situ images.
For published context on what a well-structured catalog dataset can look like, Amazon Berkeley Objects pairs 147,702 product listings and 398,212 unique catalog images with up to 18 metadata attributes per product, and links 7,953 products to artist-made 3D models (Collins et al., 2021). That is a research release built for a specific benchmark, not a template your supplier must match, but it shows how image, attribute and model linkage is usually documented.
Red flags
- The supplier cannot say which fields were entered by hand and which came from brands.
- Units are implied by column names but absent from the data.
- There is no stable product identifier linking images, attributes and any 3D models.
- The supplier has never compared records to physical items.
- Dimension values repeat suspiciously across unrelated categories.
- The file is a scrape or aggregation with unclear rights to the images and text. Rights are a separate question; see product image rights. This is not legal advice.
Limitations and extra preparation
Even a master file that passes every audit test remains a description of products, not of how they behave when handled. Nominal dimensions and weights describe a catalog item, not the unit on a given shelf: packaging revisions, regional variants and supplier substitutions drift away from the record, and an audit sample only measures the drift for the items you actually checked. Fields such as material or fragility are often free text written for shoppers, so they need mapping to a controlled list before a robot planner can use them. The file contains no images from a robot's viewpoint, no grasp outcomes and no force data; pair it with object imagery and, for manipulation, with robot or teleoperation demonstrations.
Plan for extra preparation on your side: deduplicating GTIN and internal SKU keys, converting units, flagging records with missing or implausible values as "unknown" rather than defaulting them, and re-running the audit when the supplier sends an update. Results from one category or one supplier do not transfer to another, so audit each source separately.
Questions to ask suppliers
- Which standard or schema governs the dimension and weight fields, and at which packaging level?
- What validation runs at entry, and what happens to records that fail?
- When was the last physical audit of dimensions, and what was the discrepancy rate by category?
- How are discontinued and re-packaged SKUs flagged, and how far back do images go?
- Which fields are brand-supplied versus retailer-entered?
- Is there a change history showing when dimensions were last edited?
- Can you provide a data dictionary and a datasheet-style description of how the file was assembled, in the spirit of Datasheets for Datasets?
- Who holds the rights to images and descriptions, and can they license them for model training and evaluation?
What to prepare on your side
Decide what the data is for before you audit it. Fix the attribute subset that matters, define tolerances, and reserve a held-out slice of verified records for evaluation so the audit sample is not also your training data. Normalize units, deduplicate, and attach a source column to every field. Then document the result as a datasheet so later users can see what was and was not checked.
If the audit shows the records are mostly right but physical properties are missing, the next purchase is measurement, not more catalog. See product dimensions and weights and the attribute schema.
Discuss your requirements
If you want product master data from US businesses and need it checked before licensing, describe the attributes, categories and permitted uses to SourceX. SourceX reviews the requirement and follows up about potential sources, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match.
Explore sourcing and licensing options with SourceX
Sources
- GS1 Package and Product Measurement Standard (formerly GDSN Package Measurement Rules) — Defines nominal measurement attributes and packaging levels, and the GDSN data-pool context for sharing product master data.
- ISO/IEC 5259-1:2024 Artificial intelligence - Data quality for analytics and machine learning (ML) - Part 1: Overview, terminology, and examples — Framework for assessing and improving data quality across the data life cycle, with a series covering measures and management.
- ABO: Dataset and Benchmarks for Real-World 3D Object Understanding — Example of catalog images and up to 18 metadata attributes per product paired with 3D models.
- Datasheets for Datasets — Datasheet-style documentation of composition and collection process.