Skip to content
LexDataLexData
PlatformIndustriesCustomers
DocsThe Field GuideBlogWhy models drift
AboutCareersSecurityContact
Log inStart now

// RETAIL

Checkout Product Verification

Checkout Product Verification. What it takes to run it.

Every item on the counter by class, checked against the till's own list, from the camera already over the lane.

Start with your footageBook a demo →All of retail →

// 01 · The question

“Did everything on the counter get a matching scan?”

// 02 · Why it is hard

The class list runs to every SKU that crosses this lane, many visually near identical: a small and large bottle of the same drink, two flavours in the same colour scheme, an own-brand pack that copies a branded one. It also moves every time a pack is redesigned.

// 03 · What the labels have to be

Bounding box + tracking

Decided before the first frame

An item sits on the counter across many frames between the first one down and the pay tap. A track keeps one identity on each item across that span, so a bottle picked up and set down twice is one item on the list, not two.

This is the decision that is expensive to reverse. The geometry has to match what the answer contains, and finding out it does not means labelling the set a second time.

// 03a · What it finds

Every item on the counter

a box and a class on each item set down between the first one on the counter and the pay tap, trained on this lane's own frames and this lane's own light

An item the model has not been shown

a box outside this lane's own class list, held rather than guessed at

A count against the lane's own expectation

the number of a class on the counter against the number a rule expects, read on the frame the rule names

A frame the model doubts

a crushed pack, an item still in a hand, a bottle lying label down, held for a person before the next version trains

// 03b · What it checks

  1. 01

    Each box's class against this lane's own list, so an item the model has never been shown is held rather than named.

  2. 02

    The count of a class against the rule's own expectation, with a schedule, cooldown and severity, so a true mismatch pages once and not on every frame.

  3. 03

    The list the camera saw against the till's own list is the store's own comparison; nothing on the camera reads a receipt, the camera supplies what it saw.

  4. 04

    A doubted frame held for a person before the correction retrains anything.

// 03c · What the store provides

  • The camera already over the lane. No new camera, no scale and no change to the scanner.
  • Frames from this lane, at this light, at closing time as much as opening. A product photographed on a studio background looks nothing like the same product under the lane light.
  • The store's own receipt or till feed to pair against the camera's list. The pairing is the store's own arithmetic; nothing on the camera sees a receipt.
  • Someone who receives the alert, on Slack, email or a webhook into whatever the store already carries.

// 04 · How we run it

Three parts of one loop, on this job.

LexAnnotate

Shopper Tracking

Annotate in-store video for customer detection, employee identification, door events, and product placement. Distinguish between customers, staff (by uniform), and children within each camera's region of interest.

LexInsight

Conversion Analytics

Turn raw foot traffic data into conversion intelligence. Link visual detections to store zones, time slots, and operational events. Surface patterns that static dashboards miss.

LexAlert

Store Alerts

Monitor detection accuracy across store locations. Detect when camera repositioning, seasonal displays, or lighting changes degrade model performance. Route the failures back for retraining.

How the loop fits together →

// 05 · What breaks it after launch

Concept drift

The spec changed

→Concept drift →

A packaging refresh changes the correct answer without changing the till. The class built on the old pack stops matching the new one from the first delivery, and the attendant's override rate on that one product is the signal, days before anyone opens a ticket.

It is not the only one that can get this use case, it is the one that usually gets it first. All ten conditions.

// 06 · In retail

Store Intelligence

Full write-up ↓Every case study →

The Challenge

The models lacked high-quality labeled data, activity alerts came back false, and unmonitored registers left customers waiting at checkout.

Our Execution

Labeled customer and staff positions. Validated alerts and traffic counts for accurate footfall tracking.

The Result

Faster AI training with accurate labeling. Smarter alerts for open doors and empty registers.

4M+

Annotations & validations

// 06a · Questions we get asked

Does this replace the scanner?

No. The scanner is still what rings up the sale. The camera adds a second list, what it saw on the counter by class, and a mismatch between the two lists is what gets reported, never scored by the camera alone.

Can it tell two flavours of the same brand apart?

That is the first thing checked on this lane's own frames. The small and large bottle of a drink, two flavours in the same colour scheme and an own-brand pack that copies a branded one are exactly the pairs a person checks before the model trains on the difference.

Does it ever show anything to the customer?

No. The alert reaches a person on the usual channels, console, email, Slack or a webhook, never a screen the shopper sees. A box is wrong often enough that showing it to a shopper would cost the store more than the item itself.

What happens when a product's packaging changes?

Nothing on the counter announces it. The class built on the old pack stops matching the new one from the first delivery, the attendant's override rate on that product rises, and the fix is to label the new pack from this lane's own frames and fold it in.

Read next

Product recognition at the till, the full argument for the counter against the receipt →What a packaging refresh does to a class the model was never shown →
Start with your footageBook a demo →

// 07 · Also in retail

Traffic Counting & Conversion→Checkout Queue Monitoring→Shelf & Planogram Compliance→Store Safety & Validation→Employee Activity Monitoring→All forty-one→
Traffic Counting & ConversionCheckout Queue MonitoringShelf & Planogram ComplianceStore Safety & ValidationEmployee Activity MonitoringAll forty-one →

Send us a week of this footage. We’ll show you what comes back.

Start with your footageBook a demo →
LexData
LexData

Product

  • Platform
  • Industries
  • Use cases

Resources

  • Docs
  • The Field Guide
  • Blog
  • Why models drift

Industries

  • Energy & utilities
  • Oil & gas
  • Agriculture
  • Manufacturing
  • Insurance
  • Retail
  • Robotics

Company

  • About
  • Customers
  • Careers
  • Contact

Trust

  • Security
  • Privacy
  • Terms

Stay updated

What we learn running vision models in production.

See everything.
Miss nothing.

Stay updated

What we learn running vision models in production.

Terms of use & Privacy policy

© 2026 LexData Labs · All rights reserved