Out-of-Stock Detection: Vision, Data Signals, and What Each One Misses

The money you are already losing

Retailers lose roughly 4 to 8 percent of sales to out-of-stocks. For a $400M chain the midpoint is about $24M a year, and almost all of it is invisible, because the transaction that never happened leaves no record. A stockout does not appear in your sales report. It appears as an absence: the unit that did not ring, the basket that was smaller than it should have been.

That is why out-of-stock detection exists as a category, and it is why the buying decision comes down to a single question. How does the system know a product is missing from the shelf when your inventory record still says you have eight of them?

Feature by feature, against the generic category

"Generic category" here means the median out-of-stock detection product: shelf image recognition, or an alerting layer that watches the inventory count fall to zero.

Detection is already too late

The category is named for detection, and detection is the wrong goal. By the time a shelf is empty the sale is gone, and the best a detection system can do is shorten the gap between the loss starting and someone noticing.

Prediction changes what the system is for. Ward analyses sell-through velocity, current inventory, lead times and supplier reliability to flag SKUs trending toward zero-on-hand 24 to 72 hours out, which is enough time for a replenishment to actually arrive. The output is a work list, not an alarm:

23 SKUs trending toward zero-on-hand within 48 hours. Replenishment recommendation attached. Priority: dairy and produce categories.

Supplier reliability is in that model deliberately. A SKU with three days of cover and a supplier who hits their window is fine. The same SKU with the same cover and a supplier running two days late is a stockout on Thursday, and only one of those two is worth waking someone up for.

The phantom stock problem, and why velocity is the load-bearing signal

Phantom inventory is what breaks count-based systems. The record says ten units, the shelf is empty, and nothing in the inventory number is wrong enough to trigger anything. Shrink, misplaced stock in the backroom, a receiving error, a mis-scan at the till: the count and the shelf drift apart and the system keeps reporting health.

A system watching the count cannot see this, by construction. A system watching velocity can. A SKU that sold six units a day for eleven weeks and has sold none since Tuesday, while the record still claims stock, is describing an empty shelf regardless of what the count says. That is the case that separates serious stockout prevention from an alerting rule, and it is why velocity rather than inventory level is the primary signal here.

What Ward does not do

Ward has no cameras and no image recognition. It cannot see a product that is on the shelf but in the wrong place, and it cannot see a facing that is empty while the SKU still sells fine from a secondary display. If you need the physical condition of the shelf as a fact rather than an inference, you need vision, and Ward is not that.

It is also not a replenishment system. It does not place the order. It recommends, ranks, and writes the recommendation back into the ERP or planner that does place it, gated on an approver you name.

What it runs on

Ward is a web console. Connect your POS and inventory systems with read-only credentials scoped to the schemas you name, and Ward AI reads the schema, drafts the cleaning rules and proposes how the tables relate. You approve each proposal before it binds; nothing runs on a draft.

Your data does not move. Federated query reads the warehouse in place with no second copy, and object storage in Iceberg, Delta or Parquet is read where it already lives, so there is no migration window between signing and the first prediction. An agent watching for stockouts reaches the tables you granted it and nothing else, stays read-only until you grant a write action explicitly, and leaves every query it ran in the same audit log your people are in.