The stock said available. The warehouse disagreed.
Orders kept being accepted against a number that stopped being true that morning, and every one of them became a customer who was promised a date nobody could meet.
What actually happens
Overselling is not a warehouse problem. It is what happens when the number a system promises against and the number on the shelf stop agreeing, and nothing is comparing them.
Available-to-promise is calculated from a stock figure that is synchronised from the warehouse management system. The order platform quotes delivery dates against it.
The synchronisation degrades. Not stops, degrades: a subset of movements stop flowing, typically because one message type began failing validation after a change nobody connected to inventory.
The stock figure keeps updating, so every freshness check passes. It is simply updating from an incomplete picture, and it drifts upward relative to reality because outbound movements are the ones being lost.
The order platform continues accepting orders and promising dates. Each promise is made in good faith against a number the system has every reason to trust.
It surfaces at the point of pick, when the warehouse cannot fulfil what was promised. By then the orders are placed, the dates are communicated, and the resolution is a set of individual customer conversations plus whatever the commercial team decides to offer people who were promised something that did not exist.
Every promise was made in good faith against a number the system had every reason to trust. Nothing was comparing that number to the shelf.
The same day, two ways
Measured in how many orders were accepted against a figure that had already stopped being true.
Illustrative, not measured. The times below model a scenario built from the patterns we see in production estates. They are not timings recorded at a named customer. The point is the shape of the clock, not the totals: check it against your own last ten incidents.
Today, found at the pick face
- 08:10A message type begins failing validation. Outbound movements stop syncing. Inbound continues.
- 08:10 ↓ 15:30WaitingStock figure drifts upward against reality. Freshness checks pass, because the figure is still updating.
- 15:30WaitingOrders continue to be accepted and dates promised against the drifted figure.
- 16:45Warehouse cannot fulfil the promised picks. Escalation raised.
- 16:45 ↓ 19:20WaitingSync gap identified. Failing message type traced to a change made that morning.
- Next dayAffected orders identified. Customers contacted individually. Commercial goodwill applied.
~8 hours of promises · against stock that was not there
With promise and shelf compared
- 08:44Sentinel detects divergence between the available-to-promise figure and the warehouse movement ledger, not just staleness.
- 08:46Message queue by type, recent changes, validation failures and the affected SKU set correlated.
- 08:50Cause identified: one message type failing validation after a schema change deployed that morning.
- 08:51Affected SKUs quarantined from available-to-promise automatically. Orders are held rather than promised. This is reversible.
- 08:52Action Ticket raised with the schema fix, the affected SKU list, the replay plan and the rollback path. Owner notified.
- 09:25Approved. Schema corrected, backlog replayed, figures reconciled, SKUs released. Orders promised against a true number.
~40 minutes · and no order was promised against a phantom
The measurable cost in the first column is the number of orders accepted between 08:10 and 16:45 that could not be fulfilled as promised, and your commercial team can price exactly what each of those cost to resolve.
The reason this runs for eight hours is that every check in the chain is a freshness check. A figure that is updating looks healthy, and this figure was updating. It was just updating from an incomplete stream.
The mechanism is comparing the promise to the ledger rather than checking whether the promise is fresh. Available-to-promise reconciled against warehouse movements catches a partial sync; a timestamp check never will.
Quarantining the affected SKUs is the reversible half and it happens immediately, because holding an order for forty minutes is recoverable and promising a date you cannot meet is not. Replaying the backlog touches a system of record, so that waits for an approval.
Why the number is what it is
The measurable cost in the first column is the number of orders accepted between 08:10 and 16:45 that could not be fulfilled as promised, and your commercial team can price exactly what each of those cost to resolve.
The reason this runs for eight hours is that every check in the chain is a freshness check. A figure that is updating looks healthy, and this figure was updating. It was just updating from an incomplete stream.
The mechanism is comparing the promise to the ledger rather than checking whether the promise is fresh. Available-to-promise reconciled against warehouse movements catches a partial sync; a timestamp check never will.
Quarantining the affected SKUs is the reversible half and it happens immediately, because holding an order for forty minutes is recoverable and promising a date you cannot meet is not. Replaying the backlog touches a system of record, so that waits for an approval.
The mechanism is comparing the promise to the ledger rather than checking whether the promise is fresh.
Who decides to press go
Quarantining SKUs and replaying an inventory backlog are different classes of action and are gated differently.
Quarantining affected SKUs from available-to-promise runs under policy. It is fully reversible, it prevents a promise that cannot be kept, and the cost of being wrong is a short delay.
The Action Ticket carries the schema fix, the affected SKU list, the expected reconciled figures and the rollback path. The inventory owner approves before any backlog is replayed.
Replaying inventory movements into a system of record can double-count if it is done twice, which is why it never runs without a name against it.
Available-to-promise figure updating normally and passing every freshness check. Warehouse movement ledger diverging from it. Orders being accepted and dates promised.
Message queue by type, recent changes, validation failures and affected SKU set correlated. One message type failing validation after a schema change deployed that morning.
Affected SKUs quarantined from available-to-promise. Action Ticket raised with the schema fix and replay plan, held for the inventory owner.
Promise-to-ledger reconciliation added as a standing check rather than a freshness test. Schema changes on inventory message types added to the pre-deploy validation set.
This is a platform capability, not a published customer deployment. The mechanism, which is treating a business process outcome as a signal, correlating across the systems that implement it, and then executing a governed MOP with pre-check, post-check, rollback and approval gating, is running in production today; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The back-office scenario above applies that same mechanism to a business process. The timings shown are modelled, not measured at a named customer.
If the action carries no service impact
Quarantining affected SKUs from available-to-promise runs under policy. It is fully reversible, it prevents a promise that cannot be kept, and the cost of being wrong is a short delay.
If it replays movements or corrects stock figures
The Action Ticket carries the schema fix, the affected SKU list, the expected reconciled figures and the rollback path. The inventory owner approves before any backlog is replayed.
What Sentinel did, step by step
- ObserveAvailable-to-promise figure updating normally and passing every freshness check. Warehouse movement ledger diverging from it. Orders being accepted and dates promised.
- InvestigateMessage queue by type, recent changes, validation failures and affected SKU set correlated. One message type failing validation after a schema change deployed that morning.
- ActAffected SKUs quarantined from available-to-promise. Action Ticket raised with the schema fix and replay plan, held for the inventory owner.
- OptimizePromise-to-ledger reconciliation added as a standing check rather than a freshness test. Schema changes on inventory message types added to the pre-deploy validation set.
Bring us a week you oversold
We will compare your promise figure against your movement ledger for that period.