Retail AI

Overview

This case is research and pilot planning for retail checkout control. The idea is to compare what the camera sees at the register with what the point-of-sale system records, then surface events that disagree. It is not a production computer-vision product on this site, and it has no published accuracy or savings.

Context and challenge

A cashier flow can look normal on a receipt and wrong on camera, or the other way around. Loss, mistakes, and disputes sit in that gap. Closing it means tying a video moment to a POS event and deciding which disagreements are worth a person’s attention. A raw stream of alerts is not a product.

Product thinking

The user of a pilot is not the model. It is the person who has to decide whether an event matters. The product questions are which mismatches count as incidents, how much delay is acceptable between the camera and the receipt, and what the operator does next. A demo that only draws boxes on video does not answer those questions.

System architecture

The planning model has four parts: a video stream, POS records, a comparison step that emits events, and a place where a person reviews incidents. Server-side processing is assumed, because a checkout camera should not depend on a laptop in the store. The specific models, hardware, and hosting are not selected here.

Challenges and trade-offs

A pilot has to stay small enough to run and strict enough to mean something. Processing every frame at the highest quality makes the technical bill the product. Sampling, or reviewing only moments around a POS event, is the kind of tradeoff this case has to answer before anyone talks about scale. I am not publishing a cost model. The numbers are not settled.

Reflections

The honest status is R&D / pilot planning. The next useful artifact is a narrow pilot definition: one store context, one set of incidents, one way to compare video with POS, and a clear stop condition. Until that exists, this page stays a structured brief.