Product
Prove the Rule Before You Let It Draft Orders
A rule you've written is a description of how you buy; a rule you've watched run is a fact — and there are three proofs you can put one through before it's able to spend anything.
A rule you haven't watched run is a guess with a schedule
You write a reorder rule in a single sitting, and then it runs for months. The moment you save it, it stops being a description of how you buy and becomes an instruction that will be executed: choose the supplier, the scope, and the cadence, and Assisty generates the purchase orders on time, seeded with the same suggested quantities you'd get in the Buying Table. Nothing about the act of writing it down proves it matches how you actually order.
There's a well-worn pattern for closing that gap: the parallel run. The new system runs on real, live inputs — but its outputs don't act. Humans stay the decision-maker until the outputs stop surprising them. Netstock's advice on automated replenishment puts it plainly: run parallel testing with the new system before fully transitioning, and start with your most popular SKUs. What you do with the parallel run is your own discipline — you compare its output against the order you'd have placed yourself.
Confidence gets expanded on a ramp, not flipped with a switch. And the useful thing about a reorder rule is that you can run all three on one rule, in one week. Three proofs, and none of them can spend money — the spending starts only when you approve.
| Proof | What you do | What it costs if the rule is wrong |
|---|---|---|
| One — Preview | Ask what next Monday's run would include | Nothing — no PO exists |
| Two — First cycle, untouched | Let the scheduled run land in the approval queue and leave it alone | Nothing — suppliers only ever see what you signed off |
| Three — Hand-built comparison | Stage the same morning's buy on the Purchase List and compare | One review sitting |
| Approve — the cost line | The PO becomes a real order, emailed and received against | Real money and real stock |
Proof one: ask what next Monday's run would include
The cheapest proof happens before the schedule has ever fired. You can create and manage rules in the UI, or just tell Atlas what you want — "Every Monday, draft a PO for anything from Acme below its reorder point" — and you can ask for a preview of what next Monday's run would include, before it runs.
What matters is what you judge when you ask, and the order you judge it in: membership before magnitude. A scope like "items below reorder point" is a condition, and conditions are cheap to write and easy to get subtly wrong — the wrong side of a boundary, a product you assumed was assigned to that supplier and isn't, a whole shelf that qualifies on a technicality you never considered. So ask two questions of the run. Is everything it would cover something you'd genuinely buy from this supplier this week? And is anything you'd expect to be covered conspicuously absent?
Magnitude is a different question with a different owner: the run is seeded with the same suggested quantities you'd get in the Buying Table, so a number you distrust is really a question about that suggestion's inputs — worth spot-checking on its own terms, not while you're testing scope.
Proof two: let the first cycle land untouched — then build your own
A preview tests the rule against today. The schedule tests it against a real Monday — a real week of sales behind it, real stock on hand, real arrivals in transit. That's what a parallel run exists to catch: it validates against live conditions, not just against the state you happened to be looking at when you wrote the rule.
So let the first cycle fire. Every auto-generated PO lands in an approval queue — review it, adjust it, approve it or reject it, and suppliers only ever see what you signed off. That gate is what makes this proof cost nothing: until you approve, the PO has spent no money and told no supplier anything.
Here's the practice, and it takes discipline: don't touch it. Open the drafted PO, read it, and leave it exactly as generated. Then, in the same sitting, take the third proof — build the order you would have built by hand. Work the buying table and add items to the Purchase List as you go, where the list holds them, priced with each supplier's tax and currency, until you've finished reviewing and are ready to order. On this Monday you never get ready to order: the hand-built list stays staged as a comparison artifact and is not turned into POs. You approve the rule's PO or you reject it — never both, or you'll buy the same week twice.
Now you have two lists side by side: what the rule produced, and what you'd have produced.
Read every edit as a defect, not a fix
The temptation, holding those two lists, is to fix the PO — delete two lines, add one, adjust a number, approve, move on. That's how the signal gets thrown away. RELEX makes the point well in its guide to better exception management: an exception should lead to a corrective measure, because an exception you merely handle teaches you nothing — and you'll handle it again next Monday, and the Monday after.
Every difference between the two lists is a defect report about the rule. It has a location.
| The edit you made | What it's a defect in | What to change |
|---|---|---|
| Removed a line you'd never buy this week | Scope | Tighten the scope condition |
| Added a SKU the run missed | Scope | It sits outside the condition, or outside the supplier's product assignment |
| Halved every quantity | Cadence | The run covers a longer window than the supplier's order cycle |
| The PO arrived after you'd already ordered by hand | Cadence | The schedule is out of phase with the supplier's cut-off |
| Changed one quantity | Input, not rule | It's the same suggested quantity the Buying Table gives — check its inputs |
| Rejected the whole PO | Scope + cadence | The rule isn't proven; don't re-run it unchanged |
One edit is weak evidence. A change you made on a single Monday could easily be you being wrong rather than the rule. A change you find yourself making again on the next cycle, and the one after, is a pattern — and noticing that repetition is on you, across your own cycles, not something the queue counts for you. Judge your own touch against the untouched baseline you deliberately left alone.
Resist enumerating every exception up front, too. RELEX's guide notes that defining every exception in advance rarely works. Start with the critical few and develop the rule set as you go. The reason is that a complete exception list written before the first cycle describes the order book you imagine, not the one you run.
When the rule is proven — and what keeps it proven
A rule is proven when a cycle lands and you'd have changed nothing material — same items, quantities you're willing to sign for, arriving in time to be useful. Then you approve, and the parallel running ends because the draft becomes a real order. Auto-generated POs aren't a separate species: same per-supplier grouping, tax types, landed cost, and lifecycle as the ones you create from the buying table. You email it to the supplier and receive against it when the stock arrives, exactly as always.
Proven isn't permanent, though, because the rule's premises move underneath it. Lead times get renegotiated. Products get assigned to a different supplier. A scope condition that described your catalogue in March describes a different catalogue in September. Those are changes to what the rule assumes rather than to what the rule says — which is exactly why they slip through unnoticed.
So keep proof one within reach. When something about the supplier changes, ask what the next run would include before it fires, and judge membership again. It's a thirty-second check on a rule that will otherwise spend money every Monday on your behalf — and the approval queue is still there behind it, holding the last word.