Flow
How the change came together
1Read the shape of the sales
Fire only when every clue agrees, and say on the row why it ordered.
2Test with the records hidden
Grade each call on suppliers with full stock records. The full earlier pace ran high on fuzzy gaps, so order a bit under it.
3Close the covered hole
A row counts as covered only if stock lasts at the higher demand guess too.
4Rerun saved orders
Once the tool's two bugs were fixed, it listed only the rows the new rules change. A test expects no changes when the rules stay the same.
5Rebuild stock history
Work back from today's count; drop days that stop making sense.
One product at one of my stores came out of an order at zero. Not long before, it had been one of the better sellers across the stores that carry it, and other stores in the same order were still selling it.
The ordering system works out how fast each product sells over a recent stretch, then checks how long the stock on hand will last at that pace. If it lasts past the next delivery, the row is marked covered and gets zero, and the model that handles harder rows never sees it.
This product sold well for a long time, then almost nothing lately. A few units were still on hand. A few units at a pace near zero looks like more than a year of stock. So it got zero.
Why my stockout check missed it
The system already had a check for this. When stock records show a product was out for part of the time, the system bumps the pace up to make up for it. But stock records for this supplier had only started a few days earlier, and every one of those days said in stock. So the check changed nothing. It can only correct for stockouts that are on record.
An empty shelf sells zero, and zero sales look exactly like nobody wanting it.
Reading a stockout from sales alone
The agent wrote a rule that reads the shape of the sales instead. It fires only when all the clues agree: it's one product, not a shared slot; nothing else already explains the gap; the gap is long enough to be real but not so old the product is probably dead; it sold well right before stopping; other stores still sell it; and the records here are too thin to prove the shelf was full. Then the order is sized on a bit less than the earlier pace, and the row says why. I approved that for this case only.
Testing it with the records hidden
The agent tested the rule on suppliers with full stock records, with the records hidden. Roughly nine in ten of its calls were real stockouts. The recent pace under-ordered those by about three times. The full earlier pace was right on clean gaps but ran high on fuzzy ones, so the rule orders a bit less than that.
Covered rows that ignored a known stockout
The covered check had a second hole. Even when a stockout was on record and the system had raised its demand guess, the check still used raw sales. Dozens of rows were getting zero that way. Now a row only counts as covered if stock lasts at the higher number too:
A row is covered only if the stock lasts at the sales rate and also at the higher demand guess.
The replay tool's false alarm
To see what a rule change touches, the agent built a tool that reruns every saved order with today's rules and lists what changed. Its first run said most rows changed. The tool itself was wrong in two ways, and once both were fixed, only the rows I meant to change showed up. A test now reruns saved rows under unchanged rules and expects no changes.
Rebuilding stock history
A separate change rebuilds stock history, where it was patchy, by working backwards from today's count through sales and deliveries. Where that walk stops making sense, the days are dropped as unknown instead of guessed.
I haven't rerun the order that started this yet, so I've only seen this row come out right in a test. A slow product that runs out is still the case nothing catches yet.