A shelf-execution model that detects planogram drift produces alerts, not outcomes. The gap between the two is a workflow design problem, and it is where most shelf-execution deployments quietly lose their return. The model fires, a dashboard fills, and within a few weeks the people who were supposed to act on it have learned that the dashboard can be safely ignored.
The fix is not a better detector. It is treating each detection as a bounded task with an owner, a shelf location, a priority, and a response that comes back into the pipeline — and sizing the volume of those tasks to what a shift can actually absorb.
What does the workflow after a planogram-break detection look like?
Five stages, and every one of them is a design decision rather than a default:
| Stage | What it produces | Failure if skipped |
|---|---|---|
| Classify | Break type: on-shelf stock-out, misplacement, price-tag error, promotional non-compliance | Staff receive an undifferentiated “check this shelf” and improvise |
| Locate | Aisle, bay, fixture, shelf level — not a camera ID or an image crop | Task is unactionable without hunting for the spot |
| Prioritise | Ranking derived from the SKU’s sales velocity and break severity | High-velocity gaps queue behind cosmetic facings |
| Assign | A named owner on the current shift, with an expiry at shift end | Alerts belong to everyone, so nobody closes them |
| Confirm or dismiss | A one-tap response recorded against the detection | The model never learns which of its alerts were real |
The last row is the one usually treated as optional, and it is the one that carries the most long-term weight. A confirm/dismiss response is simultaneously an operational receipt (the task was handled) and a labelled example (the detection was correct or it was not). Without it, alert precision is unmeasurable after go-live, and the only accuracy figure anyone can quote is the one from validation before the store’s lighting, packaging, and promotional overlays started drifting — a decay pattern we cover in where shelf-execution AI still fails in production.
Priority is a business input, not a model output
A detector ranks by confidence. A store ranks by consequence. Those are different orderings, and letting the first one drive the task queue is the most common design error we see in this layer.
A confident detection of a mis-faced slow-moving line and a marginal detection of an empty facing on a top-20 SKU are not equal tasks. Priority should be composed from the SKU’s sales velocity, the break class, and how long the break has already been open — with model confidence acting as a gate on whether the alert is emitted at all, not as the sort key once it is.
This also gives you a volume control. Rather than tuning a confidence threshold in the abstract, you set a tasks-per-shift budget and let the priority function fill it. The right alert volume is the one a shift can close, not the one the model can generate. If a store can absorb thirty shelf tasks per shift, emitting three hundred does not surface more breaks — it surfaces none, because the queue stops being read.
Different break types are different jobs
Bundling every detection into one “planogram break” task type is how the workflow ends up unactionable. The four classes below have different owners, different remediation times, and different escalation paths:
- On-shelf stock-out — product missing from its facing. Remediation is a backroom pull or a replenishment request; if the backroom is also empty, the task escalates to ordering rather than closing on the floor.
- Misplacement — product present but in the wrong position, often a customer-caused displacement. Fast to fix, low escalation, high daily volume, so it is the class most likely to swamp a queue if it is not rate-limited.
- Price-tag error — label mismatched to the facing. This one usually has a compliance dimension and a different owner than the replenishment team, and it should not expire quietly at shift end.
- Promotional non-compliance — the display does not match the agreed promotional layout. Time-boxed to the promotion window and often reported upward to category management, so the closure evidence matters more than the closure speed.
Treating these as one class forces staff to do the classification themselves at the point of the task, which is exactly the cognitive load the system was supposed to remove.
Which numbers show the loop is actually closing?
Detection counts are not results. The workflow layer has its own metric set, and it is deliberately biased toward closure rather than discovery:
- Time-to-restock — detection timestamp to confirmed remediation, per break class.
- Same-shift closure rate — the share of flagged breaks closed before the shift that received them ends. This is the single most diagnostic number in the set.
- Planogram compliance after remediation — measured on a re-observation, not assumed from the task being marked done.
- Alert precision from confirm/dismiss — a running estimate that decays gracefully as the store environment changes.
- Tasks per shift — the workload measure that tells you whether the system is inside its absorption budget.
The diagnostic rule is simple: if detection volume is rising while closure rate is falling, the bottleneck is the workflow, not the model. Retuning the detector at that point makes the problem worse. This is separate from proving programme-level return, which needs baselines and control stores — the method for that is in measuring on-shelf availability lift.
Why this makes shelf execution a reliability discipline
The instinct on a computer-vision programme is to keep pushing detection quality, because that is the number with a leaderboard attached to it. In shelf execution the operational ceiling arrives earlier than the accuracy ceiling. A model at a modest detection rate feeding a queue that staff trust and clear will move on-shelf availability further than a stronger model feeding a queue that has been abandoned.
That reframing changes what gets engineered. Inference cadence has to be chosen against the alert-generation rate the store can absorb, which means the capture schedule, the batching strategy, and the GPU sizing are workflow decisions as much as they are performance decisions. We size that cadence explicitly as part of our retail computer-vision work, and the same reasoning shows up in computer vision engineering generally — the throughput target is set by what happens downstream of the model, not by what the hardware can sustain.
The alert-routing and operator-confirmation patterns here are not retail-specific either. Production-floor deployments hit the same wall, with the same tell: a detection stream nobody has been made accountable for. And the boundary of what this workflow can do is worth being explicit about — the model narrows where staff look and when, which is a different proposition from replacing the round entirely.
Frequently Asked Questions
What does the operational workflow when the model flags a planogram break mean in practice?
Planogram Break Detected answers cleanly when you separate two things. It means the detection is converted into a store task before any human sees it: classified by break type, located to a fixture, prioritised, assigned to an owner on the current shift, and closed with a confirm or dismiss response. Anything short of that publishes detections rather than producing remediation.
How should a planogram-break detection be turned into a store task with an owner, location and priority?
The location must be expressed in store terms — aisle, bay, fixture, shelf level — not as a camera ID or image crop. The owner is a named person on the shift with the task expiring at shift end, and the priority comes from the SKU’s sales velocity and break severity rather than from the model’s confidence score.
How do you prioritise alerts so store staff are not swamped?
Set a tasks-per-shift budget first and let the priority function fill it, instead of tuning a confidence threshold and accepting whatever volume results. Sustainable volume is store-specific, so it is derived from observed closure rates during a pilot rather than assumed — if closure rate drops as volume climbs, the budget has been exceeded.
What does the store-staff confirm/dismiss step contribute back to the pipeline?
It is both an operational receipt and a label. Accumulated confirm/dismiss responses give a running estimate of alert precision after go-live, which is the only way to detect model drift caused by lighting changes, packaging redesigns, or new promotional overlays once validation data has gone stale.
Which metrics prove the loop is closing?
Time-to-restock, same-shift closure rate, and planogram compliance verified on re-observation after remediation. Same-shift closure rate is the most diagnostic of the three, because it degrades first when the workflow is under strain.
How does the workflow differ for a stock-out versus a misplacement or a price-tag error?
Stock-outs may escalate to ordering if the backroom is also empty; misplacements are fast, high-volume floor fixes that need rate-limiting; price-tag errors carry a compliance dimension and a different owner; promotional breaks are time-boxed to the promotion window and need closure evidence for category management. Each class needs its own owner and expiry rule.
How do you tell a workflow bottleneck from a model problem?
Compare the direction of detection volume against closure rate. Rising detections with falling closure indicates the workflow layer is saturated; stable closure with falling confirm rates indicates the model is degrading and the detector needs attention.
Making the Planogram Break Detected call
Planogram Break Detected is rarely the hard part — knowing which of its failure modes you can live with is. That answer is workload-specific, and it is worth writing down before you build.
