Development of an AI system for a cashierless autonomous store

What breaks in an autonomous store without checkout counters

An autonomous store breaks not on the very idea of "grab and go," but at the junctions between subsystems.

The first bottleneck is the queue at the entrance: if visitor identification takes noticeable time, people pile up at the turnstile, and checkout-free retail turns into an ordinary queue, only without a cashier.

Worse is when the system is uncertain about a repeat passage and directs the person to the on-duty employee.

Second is purchase recognition. Similar packaging, crumpled labeling, an item on the bottom shelf, two people passing together—each such case produces a disputed event.

If disputed events are not resolved automatically, they turn into manual reviews: an employee reviews recordings, reconciles the basket, and corrects the receipt manually.

Third is discrepancies in stock balances. The system sees that an item has been removed from the shelf, but does not always correctly determine whether it left with the customer or was returned to its place.

Accumulated noise in events is the main part of losses at the site—not theft, but unreconciled errors that no one tracks item by item.

Fourth is incidents. The more manual reviews there are, the higher the load on the duty shift and the later it becomes visible that recognition has started making errors on a specific product type.

Below we examine how this is addressed: where entrance checks are placed, how recognition events are reconciled with stock balances, and what goes into automatic review.

What changes in an autonomous store after implementation

The first measurable shift is at the service point. Average purchase time drops to the "grab and go" level: the customer scans the item or simply takes it from the shelf, and the receipt closes without a cashier.

The share of purchases closed fully automatically becomes the main metric of the site—it immediately shows where the scenario still runs into manual rechecking.

Recognition accuracy is measured not "overall" but by product types: weighed items, similar packaging, groups taken by several customers at the same time.

Where model confidence is below the threshold, the system does not guess but gathers additional evidence—it reconciles weight and asks for confirmation on the screen.

Computations run on edge modules NVIDIA Jetson: inference does not depend on the communication channel, so response remains predictable even when the network drops.

Loss reduction comes not from the camera but from linking the event to the basket and receipt. A class of failures driven by the human factor disappears: an unclosed item, the wrong product rung up, "forgotten" payment.

Incident reviews become several times fewer—for a disputed receipt there is a recording, weight, and action history, and only rare cases are checked manually.

Automation of the site shows up in shifts: a cashier ceases to be a mandatory role in the schedule, and staff handle stocking and replenishment based on sales data.

The effect scales across the chain—site metrics are compared with one another, and a deviation in accuracy or the share of automatic receipts is visible on the very first day.

Comparison of approaches: cameras, sensors, hybrid schemes

The choice of construction option is determined not by budget but by the physics of the sales floor: shelf height, density of display, share of packaged goods, and zones that are not overlapped by the field of view.

Shelf video analytics provides scalability—one camera serves several sections, and a new shelf can be added without installing sensors. Weight sensors record the fact of removal more accurately, but require stable item weight and calibration after every rearrangement.

What to choose for a specific layout

The hybrid scheme covers most mixed layouts: cameras identify the item, sensors confirm removal, and discrepancies are reviewed from a short list of events rather than the entire purchase history.

What is appropriate for your sales floor is determined by the plan and assortment—we calculate this before building the model.

Implementation stages: from site survey to acceptance

The work order is structured so that expensive mistakes are found before installation, not after launch. The survey and zone plan take more time than setting up recognition—but rework after handover costs many times more.

1. Premises survey. We visit the site, produce a plan, mark customer routes and the places where goods are taken most often. We separately record blind spots: dead corners, overlaps by shelving, glare from display cases—everything that prevents a stable view of the shelf.

2. Coverage zone plan. Based on the survey results, we calculate how many cameras and sensors are needed and at what height to install them so that adjacent shelves do not overlap each other and every item enters the frame fully, not just at the edge.

3. Recognition setup. We train the model on the site's real assortment—with similar packaging, crumpled boxes, and goods that customers move around. We configure the scales and the link to the store's accounting system.

4. Scenario testing. We run live routes: took and put back, group purchase, a child with an item, oversized goods, an attempted carry-out. Each scenario either passes or goes back for refinement.

5. Pilot operation. The store operates as usual, and the system is in observation mode: we reconcile what was recognized with actual purchases and calculate the share of receipts without manual intervention.

6. System acceptance. A control run through the agreed scenarios, verification of reporting and access, staff training, a procedure for failures, and the order for updating models for a new assortment.

Each stage is closed with a document—a report, plan, or test protocol. The work is accepted based on facts, not impressions.

What we hand over: plans, policies, procedures

Handover does not end with the launch of the point of sale. The customer retains a set of artifacts that its engineers and shift staff use without us: configuring zones, changing assortment, reviewing incidents, and updating recognition models.

• System documentation — service map, data flow diagram from cameras and sensors to the receipt, list of integrations with the accounting system, description of recognition models and their quality metrics.
• Placement plans — sales floor layout with camera, shelf sensor, and exit zone mapping; viewing angles and overlaps are indicated so that when shelving is rearranged it is clear what needs to be recalculated.
• Access policies — roles in the monitoring panel, retention periods for clips, procedure for issuing recordings, rules for changing the product catalog and trigger thresholds.
• Staff roles — who confirms a discrepancy in the basket, who handles a conflict at the exit, who is responsible for replenishment and scale calibration.
• Response procedures — step-by-step scenarios for an amount discrepancy, a false trigger, loss of connection with the exit point, and manual purchase confirmation.
• Configurations — zone and threshold settings files in version control, with change history and rollback to the previous version.
• Shift instructions — opening and closing checklist, checks of cameras, scales, and terminal, actions when the service is unavailable.

Everything remains in the customer's repository under its accounts, and access to the infrastructure is issued to its administrators.

Handover is accompanied by a walkthrough with real goods and shift training—after that, assortment and zones can be changed by the store's own staff.

Implementation example: site throughput without checkout counters

Before and after

At a site of comparable area, before switching to checkout-free mode, a purchase took 4-5 minutes: a queue at the checkout during peak hours and waiting for an employee to check weighed goods.

After launch, the average time from entrance to exit is about 1.5 minutes, and peak-hour traffic grew from 120 to 300 people: the site stopped being limited by the number of checkout positions because payment and recognition run in parallel across the entire sales area.

Metrics before and after

• Share of auto-closed purchases: 94% of receipts close without staff involvement versus 62% at launch.
• Manual reviews: from 40 to 9 per day—only disputed sessions remain, where the item needs to be verified visually.
• Average purchase time: 4.5 minutes → 1.5 minutes for a basket of 5-7 items.
• Entry denials dropped by a factor of three after payment verification was moved to the exit stage.

What was refined after launch

During the first week, the system confidently closed beverages and packaging, but made errors on weighed goods and baked goods—these were allocated to a separate zone with additional coverage, and recognition was additionally trained on the local assortment.

The "suspicious session" scenario was changed from calling an employee to soft confirmation on the screen: the share of auto-closed receipts grew, and the load on staff fell.

Integration with the loyalty program of a chain of neighborhood stores was connected at an already operating site—customer identification and point deduction occur at the moment of exit.

What to do if a self-checkout is already installed

The path is chosen based on the state of the already installed system. If the self-checkout outputs events and the cameras cover the display and exit zones, we build recognition on top of the existing equipment.

If the protocols are closed by the manufacturer and coverage is fragmentary, it is more honest to consider a full replacement; the intermediate scenario is a hybrid mode with an operator.

Site modernization begins with an inventory: the checkout model, sensor composition, what software is already installed, and whether there is access to the event log.

Then we run recordings from the real cameras through recognition and look at the share of correctly recognized baskets—that is what decides whether to build on the system or change the setup.

We work with open computer vision libraries, such as OpenCV: the model is trained on recordings from cameras that are already installed, without replacing the optics.

Solution compatibility is the main risk of such projects, so we test it in a pilot at one site before rolling it out across the chain. Describe what is installed and which scenario needs to be covered—we will come back with a modernization plan and an estimate.

Technical doubts: we answer substantively

Engineering doubts about an autonomous store arise at the junctions of scenarios: how the system distinguishes customers, what happens when communication drops, and what confirms the fact of purchase. Below are short answers on each point; we expand on details for a specific site.

What happens when communication fails?

The site continues to operate locally: events are written to a buffer, and the purchase is not blocked. After the channel is restored, the data is sent and reconciled with the result, and discrepancies go into a report to the operator.

How is the system protected against item substitution?

The event is confirmed by several independent signals: zone state, shelf position, basket movement. Substitution produces a mismatch, and the episode enters the manual review queue.

Can a store be launched in stages?

Yes: first one zone or part of the assortment, then reconciliation of automatic write-offs with actual ones. Expansion only after stable matching, so as not to scale the model error.

How are roles and access permissions separated?

A floor employee, a process engineer, and audit have different rights to view and edit settings. Changes are logged with the author indicated, and purchase data is available strictly according to the procedure.

Let's discuss the task: what we need from you for an assessment

To move from discussing the task to a work plan, we need inputs about the site: both the architecture and implementation timelines depend on them.

An autonomous store without checkout counters relies on a combination of cameras, weight-sensing shelves, and access control, so assessment begins not with code but with the site's physical layout and customer scenarios.

• Sales floor layout — a plan with zones and aisles: camera placement and blind spot coverage depend on it.
• Number of entrances and exits, open passage or turnstiles: how many identification points operate simultaneously.
• Assortment — piece goods, weighed goods, mixed: determines the required recognition events.
• Operating hours and peak hours: whether an on-duty employee is needed and how the system behaves when people gather.
• Access control requirements — QR, card, biometrics — and rules for guests, couriers, and staff.
• Payment and return scenarios: app, linked card, payment at exit.
• Existing infrastructure — cameras, internet, electrical wiring: what we reuse and what we purchase additionally.

Based on these inputs, we assemble a work plan: stages, launch order, acceptance points, and team composition—machine vision engineers, integrators, a hardware specialist, and a project manager.

Implementation timelines depend on the area and number of scenarios, so we state them after the review, not before. Describe the task—we will come back with an estimate and plan.