Suppose a planogram compliance computer vision system suddenly starts raising false alerts at three chains and nowhere else. The safest working assumption is an environment or planogram change, and it stays the assumption until a controlled test says otherwise. The diagnosis takes two steps. First, compare the affected stores with the unaffected ones on lighting, camera or rig angle, planogram version and pipeline version. Then reprocess the same stored images through the old and new model and pipeline versions. If both versions give the same false alerts on those images, the update is not the cause: look at the stores, the planogram data or something both versions share. If they disagree, the update changed something.

TechnoLynx treats this as production AI reliability work. Its Production AI Monitoring Harness builds evaluation harnesses, regression suites and drift detection. The first step would be gathering the stored images and alert logs from the affected and unaffected chains.

If the model is otherwise accurate, why do a handful of false alerts matter?

A compliance system loses its value when store teams stop acting on its alerts, and false alerts teach them to stop. An iFactory deployment checklist puts it plainly: every “misplaced product” alert that comes from an outdated planogram is one the store team learns to ignore, and once they ignore those they will ignore the real ones too. Fygurs describes the same failure for poor lighting and camera angles, which produce high false-positive out-of-stock alerts that erode staff trust in the system.

A 2025 Scientific Reports study describes a planogram system deployed across more than 7,000 7-Eleven stores in Taiwan. Citing the Hyb-SMPC research, the authors note that incomplete or misleading compliance reports reduce trust in automation and force extra manual checks, which defeats the purpose of using computer vision in the first place. They also observe that a system performing well in one store configuration may struggle in another.

A failure concentrated in one camera, environment or store group disappears inside an aggregate metric. Chain-scale planogram compliance is production retail deployment, the ground our AI engineering for retail work covers.

Is the spike in our planogram compliance computer vision alerts the stores or the model?

Start with the shape of the spike. A regression shipped to the whole fleet should appear across the whole fleet, so a spike confined to three chains points to something those chains share. The first comparison is therefore affected against unaffected stores, on:

• lighting levels
• camera or rig angle
• the planogram version in force and the date it went live
• camera firmware
• the preprocessing version that produced each image

n-base recommends a related slice comparison before retraining. Its advice is to compare training, validation and current production slices, including camera and preprocessing versions, because some apparent data shift is really a crop, resize, colour-conversion or configuration change.

If a factor differs systematically between the two groups, treat it as a suspect. It is not yet a verdict. A survey of drift detectors explains why: a change in the input distribution does not always affect predictor performance, so distribution-based detectors can raise false alarms. The survey calls the case where inputs shift but the decision boundary stays put “virtual drift”. Performance-based detectors react only when performance is actually affected, so they handle false alarms better. Accuracy alone is not always a reliable sign of performance loss either, and that is one reason drift detectors draw criticism for false alarms. In practice this means a measured difference between store groups tells you the stores look different. It does not tell you that the difference is what fires the alerts.

Putting a number on how different the store groups look

Two methods turn “these stores look different” into something you can measure. The authors of one study found that, across the dataset shifts they explored, two-sample testing using pre-trained classifiers for dimensionality reduction performed best. They also found that domain-discriminating classifiers helped characterise a shift and judge whether it was harmful. Here the two samples would be images from the affected chains against images from unaffected chains, or the same chains before and after the alerts began.

The population stability index (PSI) is another option. You bin a feature, compare the share of source and target data that falls into each bin, and the index grows as the two distributions diverge. One study found PSI highly to moderately sensitive to Gaussian and salt-and-pepper noise under both day and night lighting. The same authors set out its limits clearly. There is no established, reliable way to set PSI thresholds that indicate a shift, and binning throws away where in the image the change happened. So PSI helps detect that one group’s images have shifted. It cannot explain why the alerts fire.

Which site changes set off false compliance alerts?

We group the causes in these sources into four kinds of site change, plus genuine model decay. The order in the table below is ours, ranked by how cheap each cause is to confirm, not by how common it is, which none of these sources measures.

Causes in the order they are cheapest to check

Cause	How it shows up	Cheapest check
Stale or unversioned planogram reference	Correctly stocked shelves flagged as non-compliant	Check that compliance was measured against the right planogram version for the date
Lighting change (glare, shadow, over- or underexposure)	Errors cluster under one lighting condition or camera	Slice errors by lighting and camera; verify exposure, white balance and preprocessing consistency
Camera or rig angle, or obstruction	Partial or distorted shelf views with missing facings or price tags	Compare the framing of stored images before and after the spike; look for blocking signage
Pipeline or configuration change	Apparent data shift that is really a crop, resize, colour-conversion or configuration change	Diff crop, resize, colour-conversion and configuration versions
Genuine model degradation	Error rises gradually or abruptly with no matching site change, or the error spread widens	Reprocess a fixed reference set and track error and its spread over time

We put the planogram reference first because it is the cheapest check. The iFactory checklist calls stale planograms the single most common blocker in retail vision rollouts and the failure mode that erodes associate trust fastest. Treat that as a vendor’s judgement, not a measured rate. A store reset that reached the shelves before it reached the reference data produces exactly the pattern in question: a few chains, a sudden start, and a model that is detecting products correctly against the wrong target.

Lighting is next. iFactory notes that aisle lighting which looks fine to a shopper is often several stops too dark for a shelf-edge camera. Swifttech3 warns that lighting and camera-angle differences between stores can quietly wreck computer vision accuracy if nobody standardises capture conditions. Research on post-deployment shift lists changing indoor light angles and lens reflections among the conditions that degrade deployed models.

Camera angle and obstruction matter because the camera has to see every facing it is responsible for, in the lighting it will actually work under. An arXiv warehouse fork-anomaly study found that generalising from the lab to real facilities depended on maximising image similarity, through camera positioning, image triggering, model selection and ensembles.

Does reprocessing the same shelf images prove the alerts were environmental?

Reprocessing holds the images fixed and changes one thing at a time. Three variants answer different questions:

1. Old against new model and pipeline on the same images. If the previous version produces the same false alerts on the new images, the model update is not the cause and something both versions share is. If only the new version produces them, the change you shipped is the cause.
2. The same images against a corrected planogram reference. If the alerts disappear when the reference matches what merchandising actually shipped, the planogram data was the cause.
3. The same images through corrected preprocessing. If restoring the earlier crop, resize or colour conversion removes the alerts, the cause was the pipeline, not the model weights.

Lighting and angle are harder to test this way. A photo taken in a dim aisle or from a knocked rig cannot be convincingly re-lit or re-framed after the fact. For those causes, the corrected-condition test means fixing the site, recapturing the affected shelves, and running the unchanged model on the new images. If no model update shipped during the period, the first variant has nothing to compare. The question then becomes site change against decay, which is covered below.

A rerun that removes the false alerts is strong evidence for those images and that cause. If several things changed at the affected chains at once, separating them may still need targeted data collection with one change undone at a time.

How do we show the client the false alerts come from the stores, not the model?

A comparison holds up in front of a client when both sides use the same underlying images. Otherwise any difference in the photos becomes a confound the client can reasonably question. The steps below build on n-base’s pre-retraining workflow and run in order.

1. Preserve each alert’s evidence: the image, box, predicted class, score, model version and preprocessing version.
2. Confirm that each alert really is a false positive under the current policy. Where possible, check it against physically verified shelf state.
3. Categorise each failure as a background detection, wrong class, duplicate box, localisation error or downstream interpretation error.
4. Slice results by chain, camera, lighting condition and preprocessing version. Keep a broad random sample alongside the targeted slices: the random sample estimates general behaviour, and the slices show whether a known failure was fixed.
5. Run the reprocessing variants on the stored images and present the before and after outputs side by side for the same shelves.
6. After the fix, run the system alongside the existing shelf audit and measure its false-positive rate against what associates find when they walk the aisle.

The baseline capture needs to cover every shift and every day of the week. Cutting baseline capture short is the fastest way to end up with constant false alerts on the days that matter most. Checking a model across every store’s cameras and lighting calls for stratified evaluation by site, camera and lighting instead of one blended metric; showing the three chains the fix holds calls for change-triggered revalidation, monitoring and rollback.

Do planogram compliance models deteriorate over time?

Deployed machine learning models generally do. But we would expect decay to leave a different signature from a site change. Vela and colleagues (Scientific Reports, 2022) tested 128 model-dataset pairs across healthcare operations, transportation, finance and weather data, and observed temporal degradation in 91% of them. None of those were vision tasks, so the figure frames the risk for planogram models without measuring it. The authors argue that this “AI aging” is a separate phenomenon: data drift can trigger it but cannot fully explain it. Degradation can build gradually or break abruptly after a long period of good performance. It can also show up as a wider spread of errors while the median error still looks healthy. They name seasonality and regular equipment upgrades among the hidden variables that change model quality over time.

From these findings, the distinction we would draw is this. Decay is measured against time since the last training cycle. A site change follows a date and a place, and it lines up with something that happened in those stores. A spike confined to three chains, starting in one week, matches the second pattern much better than the first.

Two further signals help separate them. The 7-Eleven system outputs an “Unknown” result when shelf conditions deviate significantly from its training data. A jump in that kind of uncertainty output at the affected chains is a cheap early sign that their inputs have moved. The same study tested generalisation by holding out an entire unseen store. That kind of store-level held-out set gives you a reference for how the model behaves in a new environment when it is working normally.

Model choice also matters. In the warehouse study, three models trained in the lab were run on 1,089 images from a new facility, and their false-positive rates ranged from 6.61% for Grounding DINO to 96.79% for RTMDet. The same environmental shift can therefore produce very different false-positive rates depending on the architecture.

Who can help us tell environment effects from model regression across our stores?

TechnoLynx provides task-specific evaluation harnesses, regression suites and drift detection for computer vision systems in production through its Production AI Monitoring Harness. For a planogram deployment, that means a harness with slice metrics by chain, camera and lighting, plus regression and drift checks. Whether to build this in-house or bring in a specialist depends on your team. A specialist helps most when the diagnosis has to convince a client and no regression harness exists yet. Whoever you choose, ask how they will preserve and version the evidence before they propose retraining. Computer Vision R&D covers cases where the fix needs model-side work.

The engagement has limits. If the cause is a stale planogram feed, the fix is to automate the feed and version-control the layouts.

Fix the narrowest thing the evidence supports

n-base puts the principle plainly: retraining is one possible next action, not the default first step. The alternatives it lists are fixing labels or pipeline logic, adding hard negatives, adjusting a threshold, collecting targeted examples, or retraining and validating. Each diagnosed cause maps to one of them. A stale reference needs a versioned planogram feed. A dark aisle needs dedicated illumination where ambient light falls short. Moving a threshold has a cost in added false negatives, so test it on labelled slices before shipping it.

Retraining on images from a badly lit aisle teaches the model to tolerate a fault the store should have fixed, and the next lighting change starts the cycle again. The hard case is the store that had a planogram reset and a lighting refit in the same week. No amount of reprocessing separates those two. Recapture with one change undone, and accept that the diagnosis takes a few more days.