A retailer asks for “a folder of product photos” — one clean render per SKU, scraped from the catalogue. That request is where most retail recognition projects quietly begin to fail. The dataset looks complete. It passes a demo. Then the catalogue crosses a thousand classes and the automation rate starts sliding, and nobody can say why. An SKU dataset is not a folder of product photos. It is a living asset engineered for the failure modes that production actually produces: near-duplicate packaging, seasonal repackaging, lighting variance, occlusion on a crowded shelf, and the steady arrival of new and unknown SKUs. The structure of that asset — not the model architecture, not the GPU — is what determines whether recognition degrades gracefully or forces a full redeploy. That is the claim worth internalising before anyone writes a training loop. What does working with an SKU dataset involve in practice? Strip away the jargon and an SKU dataset is a mapping: from images of a physical product to a stable identifier (the stock-keeping unit) that the rest of the business already uses. A recognition model learns that mapping. When a camera on a shelf, at an intake dock, or in a shopper’s phone sees a product, the model returns the SKU — or, crucially, returns “I don’t know.” The naive mental model stops at “one image, one label.” In practice the dataset carries far more than labels. It encodes how a product can appear: front-facing and rotated, well-lit and shadowed, pristine and dented, alone and wedged between two visually similar neighbours. It also encodes what the model should do when a product is not in the catalogue at all. A dataset that only teaches the model what things look like — without teaching it the boundary of its own knowledge — produces a system that guesses confidently on products it has never seen. In retail, a confident wrong guess is worse than an honest abstention, because it silently pollutes downstream replenishment and stock data. This is why we treat the dataset as an engineered artifact with its own lifecycle, not a one-time data dump. It gets versioned, audited, and extended as the catalogue moves. The SKU110K dense-shelf detection benchmark is a useful reference point for how hard the shelf case really is — thousands of tightly packed, partially occluded products in a single frame — and how far that is from a catalogue render. What a production-grade SKU dataset contains beyond one clean image The gap between a demo dataset and a production one is mostly the material the demo omits. A catalogue-clean set has the studio render and nothing else. A production-grade set is built around the conditions that break the studio render. Concretely, a production SKU dataset carries: Multiple views per class — front, angled, top, and back where the back is what a stocker actually photographs. Packaging text and logos read differently at each angle. In-situ shelf captures — the product where it lives, under store lighting, partially occluded by price rails and neighbours, at the resolution the deployed camera delivers. Near-duplicate discrimination pairs — the 500ml and 750ml of the same brand, the regular and sugar-free variant, the two flavours that share 90% of their packaging. These are the classes a model confuses, and they need dense, deliberate coverage. Seasonal and repackaging variants — the same SKU in its holiday livery, the mid-year label refresh. If the dataset only knows one look, the model treats a repackage as an unknown. Negative and unknown-object material — images of products not in the catalogue, plus non-product clutter, so the model can learn where its competence ends. That last category is the one most teams skip, and it is the one that most directly governs behaviour in production. Without explicit unknown-object provisioning, the model has no examples that map to “reject,” so it maps everything to the nearest known SKU. The dataset’s structure is what makes the confidence score a usable operational signal rather than a number that looks calibrated in the lab and lies on the shelf. How many images per SKU class do I need? The honest answer is that there is no universal number, because the requirement is set by within-class variance and between-class similarity, not by a headcount rule. A SKU with distinctive packaging and low visual competition needs relatively little; a SKU that shares its shelf with three near-identical variants needs far more, weighted toward the views that separate it from its lookalikes. What matters more than a raw count is a per-class coverage target: an explicit, auditable statement of which conditions each class must be represented under. This is the mechanism that keeps a dataset honest as it grows. The table below sketches how coverage targets shift with catalogue size — the numbers are illustrative planning heuristics from the kind of retail engagements we work on, not a benchmarked rate, and any real target has to be validated against your own confusion matrix. Coverage-target planning sketch (illustrative) Catalogue size Dominant risk Coverage emphasis Unknown-object handling < 500 classes Lighting & angle variance A handful of views per class; light shelf capture Small negative set; often deferred 500–1,000 classes Emerging near-duplicates Discrimination pairs identified and over-sampled Explicit reject class established 1,000–2,000 classes Near-duplicate density + repackaging Per-class targets weighted by confusion risk Provisioned negative stream, refreshed per season 2,000+ classes Unknown-SKU arrival rate Coverage audited continuously; long tail sampled Unknown-object rate monitored as a first-class KPI The pattern to read out of this table: as the catalogue scales, the work shifts away from “more images everywhere” and toward targeting variance where the model actually confuses classes, plus provisioning for the unknowns that a large catalogue guarantees. This is an observed pattern across catalogue-scaling projects, not a fixed schedule — the transition points depend on how visually crowded your specific catalogue is. How to structure the dataset to handle new, repackaged, and unknown SKUs Retail catalogues are not static, so a dataset that assumes a fixed class list is designed to break. Three kinds of change arrive constantly, and each needs a structural answer. New SKUs arrive on a schedule the merchandising team controls, not the ML team. The dataset structure has to allow a class to be added and covered to target without disturbing the classes already trained. That means class identity is anchored to the stable business SKU, coverage state is tracked per class, and a class can be marked “below target” so retraining knows exactly what to pull in. Repackaged SKUs are the subtle case. The SKU identifier does not change, but the appearance does. If the dataset treats appearance as identity, a repackage looks like a brand-new unknown and the automation rate drops for that product until someone notices. Structuring the dataset so multiple appearance variants can attach to one SKU is what prevents a routine label refresh from becoming an incident. Unknown SKUs — products genuinely not in the catalogue — must have somewhere to go. The dataset needs a maintained negative/unknown stream so the model learns a reject boundary rather than forcing every input onto a known class. This is the same discipline that keeps alerting systems honest in other domains; the unknown-pattern loop used in anti-money-laundering alerting solves a structurally identical problem — a model that must flag “this is outside what I was trained on” rather than guess. Why catalogue-clean SKU datasets fail on real shelf conditions The failure is not dramatic; it is quiet, and that is what makes it dangerous. A catalogue-clean dataset trains a model that is excellent at recognising studio renders and poor at recognising the same product on a shelf. In a demo — which uses clean images — the numbers look great. In production, three things go wrong at once. First, lighting and occlusion move the input distribution away from what the model saw in training, so recognition confidence drops across the board. Second, near-duplicate packaging that the studio render never disambiguated causes systematic confusion between visually similar variants — the model is not wrong at random, it is wrong in a consistent, hard-to-spot way. Third, and most corrosively, the unknown-object rate silently rises: products the model cannot place get either misclassified or dumped into low-confidence limbo, and the automation rate falls without any single obvious cause. The divergence point is reliably around the thousand-class mark in the catalogues we have worked with. Below it, a catalogue-clean dataset can limp along. Past it, near-duplicate density and unknown arrival rate compound, and the catalogue-clean approach collapses while a dataset built with per-class coverage targets and unknown provisioning holds its automation rate. Understanding why the same product recognises well online and poorly in-store is one reason visual search and CBIR retrieval behave differently in-store versus in the app — the input conditions are not comparable, and a dataset that ignores that will underperform on one of them. How dataset structure enables scoped retraining instead of a full redeploy Here is where structure pays back most directly. When something degrades in production — a new range lands, a supplier repackages, a store rolls out different lighting — the question is whether you can scope the fix or must restart. A dataset with per-class coverage tracking and stable SKU identity supports scoped retraining: you identify the classes below target or drifting, pull in targeted new material for exactly those classes, and retrain incrementally. The trigger is legible because coverage state is visible per class. A catalogue-clean, unstructured dataset offers no such handle — you cannot tell which classes are the problem, so the only reliable move is to rebuild and redeploy from scratch. That is the difference between a maintenance task measured in a sprint and a project measured in quarters. This is also why we advise treating dataset engineering as part of the computer-vision scoping conversation from the outset, not as a data-collection afterthought. The decisions made at dataset-design time set the ceiling on how cheaply the system can be maintained for years. How labelling discipline and per-class coverage affect confidence thresholds Confidence thresholds are the store-side control surface: the value at which the system trusts a recognition versus routes it to a human or an unknown queue. Those thresholds are only as trustworthy as the dataset behind them. Sloppy labelling — a variant filed under the wrong SKU, an occluded image labelled as if it were clean — teaches the model a distorted decision boundary, which shows up as a confidence score that does not mean what the operator thinks it means. Thin per-class coverage does the same: a class the model barely learned produces overconfident errors on inputs near its scarce examples. When coverage is even and labelling is disciplined, a fixed confidence threshold behaves consistently across the catalogue, and the operator can set one policy that holds. When it is not, the same threshold is too strict for well-covered classes and too permissive for thin ones, and no single value works. The Open Images V7 dataset is instructive here on what public data does not give you: broad coverage of generic categories, but nothing about your SKUs, your packaging variants, or your reject boundary. Retail recognition at the SKU level is a bespoke-data problem, and the labelling discipline is yours to own. FAQ What should you know about an SKU dataset in practice? An SKU dataset maps images of a physical product to a stable stock-keeping-unit identifier that the business already uses. A recognition model learns that mapping and returns either the SKU or an honest “unknown.” In practice it is an engineered, versioned artifact that encodes how each product can appear and where the model’s knowledge ends — not a one-time folder of labels. What does a production-grade SKU dataset contain beyond one clean image per product? It carries multiple views per class, in-situ shelf captures under store lighting and occlusion, near-duplicate discrimination pairs, seasonal and repackaging variants, and — most often skipped — explicit negative and unknown-object material. That last category teaches the model where its competence ends, which is what keeps it from confidently misclassifying products it has never seen. How many images per SKU class do I need, and how do coverage targets change with catalogue size? There is no universal count; the requirement is driven by within-class variance and between-class visual similarity, not a fixed number. Use per-class coverage targets — auditable statements of which conditions each class must appear under. As the catalogue scales past a thousand classes, effort shifts from “more images everywhere” toward targeting confusion-prone variants and provisioning for the unknown SKUs a large catalogue guarantees. How should I structure an SKU dataset to handle new, repackaged, and unknown SKUs? Anchor class identity to the stable business SKU, track coverage state per class, and allow multiple appearance variants to attach to one SKU so a repackage is not mistaken for a new unknown. Maintain a negative/unknown stream so genuinely out-of-catalogue products have a reject boundary to learn, rather than being forced onto the nearest known class. Why do catalogue-clean SKU datasets fail on real shelf conditions? Studio renders never expose the model to store lighting, occlusion, or near-duplicate packaging, so shelf inputs fall outside the trained distribution. Confidence drops, similar variants get confused systematically, and the unknown-object rate rises silently. The collapse reliably shows up past roughly a thousand classes, where near-duplicate density and unknown-arrival rate compound. How does dataset structure enable scoped retraining instead of a full redeploy? With per-class coverage tracking and stable SKU identity, you can identify exactly which classes are below target or drifting, pull targeted material for only those classes, and retrain incrementally. An unstructured catalogue-clean dataset offers no such handle, so the only reliable fix is to rebuild and redeploy from scratch — a quarter-scale effort instead of a sprint. How do labelling discipline and per-class coverage affect confidence thresholds in the deployed model? Confidence thresholds are the store-side control for trusting a recognition versus routing it to a human. Disciplined labelling and even per-class coverage make a fixed threshold behave consistently across the catalogue. Sloppy labels or thin coverage distort the decision boundary, so the same threshold is too strict for well-covered classes and too permissive for thin ones, and no single value works. Before committing to a build, it is worth asking whether your current dataset’s coverage and labelling structure can actually support graceful degradation — or whether it will surface as falling automation once the catalogue grows. That is the question our retail computer-vision practice frames as a dataset-readiness assessment: not “how good is the model,” but “will this dataset hold its automation rate at 2,000 classes, or force a redeploy the first time a supplier changes a label?”
