Short answer
A planogram is a store's specification of where each product should sit on a shelf: position, facings, depth and sometimes height. For a restocking robot it defines the target end state of the task. It does not show how to pull a carton from a tote, align it on a pegged shelf or recover from a toppled stack.
The buyer's problem
A restocking task has two questions: where does each item go, and what does a correct shelf look like when finished? Perception and manipulation data answer the how. Planograms answer the where, and they provide the reference against which a finished shelf can be compared.
Retailers and merchandising firms produce planograms through space-planning software, often per store format or cluster. The files link products to shelf positions, counts and sometimes promotional rules. Each planogram is a structured target; combined with a photo of the actual shelf, it becomes a basis for a verification step that states what is missing, misplaced or mispriced.
What the research context shows
Shelf images are a studied perception problem. SKU-110K is an annotated dataset of densely packed retail shelves aimed at tightly packed, often identical objects, and the accompanying work introduced a Soft-IoU layer and an EM-Merger unit for detection in such scenes, with additional evaluation on the CARPK and PUCPR+ counting sets (Goldman et al., 2019).
The takeaway for a buyer is limited but practical. Detecting items on a shelf is separate from knowing where each should be. A planogram supplies the second half of the comparison. Perception data, such as shelf images and product catalogs, supply the first half; see product catalog data for robot perception.
What planograms can support, and what they cannot
| Use | What the planogram contributes | What else is needed |
|---|---|---|
| Target end state for restocking | Expected product at each position, facings, depth | Perception to read the live shelf |
| Compliance scoring | Match score between photo and plan | Labeled photos of real shelves, including non-compliant ones |
| Task sequencing | Which shelf bays and products to handle first | Store-level rules and replenishment lists |
| Instruction generation | Language such as "place three facings of X on shelf 2" | Verified wording; see image-text pairs from procedures |
| Evaluation sets | Defined correct outcomes | Held-out stores, formats or times |
Planograms are idealized. Real shelves differ because of stock-outs, damaged goods, seasonal displays and partial resets, so a planogram describes intent rather than reality. They also say nothing about the physical product: weight, packaging fragility, how a bag deforms, or how a bottle behaves when pushed. For manipulation, see object recognition data vs manipulation training data.
Illustrative planogram package
# Illustrative only - synthetic example, not an available dataset
package: shelf_layouts_v0
source: planogram files from one retailer (several store formats)
files:
layout: structured export (e.g., JSON or CSV) per fixture
reference_image: schematic or rendered diagram per fixture
fixture:
fixture_id: fx_0412
type: gondola_4_shelf
dimensions_mm: {width: 1200, depth: 450, shelf_pitch: 350} # synthetic
positions:
- shelf: 2
x_mm: 300
sku: sku_000731 # alias, not a real UPC
facings: 3
depth_units: 4
orientation: front_label_out
rules: [no_mixing_across_facings, price_label_below_product]
version: "reset_2026_03"
excluded: sales data, supplier funding terms, store addresses
rights: internal training and evaluation; retailer and brand names removed
The orientation and depth_units fields are what a robot needs for placement; many exports omit them, leaving facings only.
Preparing planograms for robot use
Space-planning software exports vary, so expect field mapping work. Units, coordinate origins and shelf numbering conventions (top-down or bottom-up) differ. Convert them to a single convention and record it.
Link each product to a catalog record or alias so a perception module can match the shelf item to the planned item. If you plan to train on the images, remember that a planogram diagram looks nothing like a camera view; paired real shelf photos with matching dates are needed to create an image-plus-target dataset.
Planograms also depend on the store operations around them: stocking from backroom, rotation rules, price-label handling and safety around ladders and carts. These live in store procedures; see retail store operating procedures. Before and after states for a restock job can be framed as preconditions and postconditions.
Acceptance criteria you can set
- Schema completeness. Share of positions with product, facings, depth and orientation.
- Version clarity. Each layout has a reset date and a store-format scope.
- Alias resolution. Every position maps to an item identifier that does not reveal a brand if redaction is required.
- Diagram-to-data consistency. Spot-check that the picture and the file agree.
- Pairing. If you need real photos, state how many fixtures have dated photos within the planogram's validity window.
- Held-out design. Decide whether you will hold out by store, format or reset period; planogram families repeat strongly across stores of the same format.
Rights and commercial sensitivity
Planograms can reflect negotiated placement deals with brands, category strategy and private-label priorities. Retailers may treat them as confidential. Product images embedded in planogram software may come from brands or data providers under separate terms. Ask whether the retailer can grant rights over layout data without needing brand approval, and which fields are excluded. Document-level redaction approaches are covered in redacting SOPs.
Limitations
A planogram is a plan: it cannot confirm that a shelf was ever built that way. It does not show shelf appearance, lighting, price tags, damaged packaging or customers in the aisle. Dense shelves with near-identical items, the situation described in the SKU-110K work, make visual verification of each facing difficult regardless of how good the target is. And manipulation of the product still requires robot-collected or demonstration data.
Questions to ask suppliers
- Which planogram software produced the files, and what formats can be exported?
- Are layouts per store, per cluster or per format?
- Do exports include orientation, depth and height, or facings only?
- How often are resets issued, and are historical versions retained?
- Are there dated photos of fixtures that correspond to specific planogram versions?
- Does the data include supplier-funded displays or promotional rules that are contractually restricted?
- What identifiers does the data use, and can they be replaced with aliases?
- Can the retailer license layouts without store location data?
Discuss your requirements
If you are specifying a retail restocking task, describe the store formats, file types and permitted uses to SourceX. SourceX looks for US businesses that hold suitable files, 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 SOPs and procedural data hub. See also the checklists as success criteria page and the catalog entry for product catalogs and descriptions.
Discuss your humanoid training-data requirements with SourceX
Sources
- Precise Detection in Densely Packed Scenes — SKU-110K is an annotated dataset of densely packed retail shelves, targeting tightly packed and often identical objects.