One Bad Automatic Order Eats a Week of Margin

Planning and procurement tools now cut real purchase orders, move real inventory, and rewrite production orders on their own. When one gets it wrong, someone pays the expedite freight to unscramble it, or a customer ship date is missed.

• The action is real, not a recommendation. An agent that writes to ERP has already committed the company by the time a human sees it.
• Most of these tools never reach production. McKinsey's 2025 State of AI survey found most organisations still have AI in experimentation or pilot rather than in production. Our own reading of manufacturing is narrower: the floor cannot check a call it cannot see.
• No vendor ships the layer underneath. Every tool governs its own actions. Nothing governs actions across the tools an operation actually runs.

The order still gets placed. It stops for a moment at the point of write, where the state it assumed can still be checked.

• Re-read at the moment of write. The plan the agent acted on may be minutes old, so stock, lead time and open commitments are read again before the order is allowed through.
• Wrong quantity and wrong timing stop here. The failure this catches is an order that is operationally wrong: too much, too early, or against a supplier who cannot deliver it.
• Your thresholds, enforced not requested. Value bands, supplier status and exception types decide what passes and what waits for a buyer.
• A plain-language record of every call. What the agent proposed, what was checked, what happened, and who approved it.

The checkpoint is not a review queue bolted to the end of the process. It sits on the write path, between the tool that decided and the system that would have recorded the decision as a fact.

• What it reads. On-hand and in-transit stock for the part, the supplier's current standing on the approved list, the lead time actually being quoted, and every open order or reservation already against the same demand. Read at the moment of write, not inherited from the plan run.
• What it writes. The purchase order, inventory move or production order, unchanged, once it passes. A clean order is not rewritten or improved. It is allowed through as proposed or it is stopped.
• What it is never allowed to write. Anything outside the workflow it was scoped to. It has no write path to master data, supplier records or contract pricing, so the rule cannot be widened by the thing the rule governs.
• Who gets asked. The buyer who owns the category, not a shared queue. The hold arrives with the order, the rule that stopped it, the live position that failed, and an approve or reject that takes one action.
• What is kept. What was proposed, which rules cleared, which check failed, who decided, and when. Held orders are retained as carefully as released ones, because the prevented order is where the saving is evidenced.

The tool that placed the order is the tool grading it.

A checkpoint is worth something only when it has no stake in the order going through.

Two failure modes matter more than the ones a demo shows. The first is a checkpoint that reads stale data and blesses a bad order. The second is a checkpoint that holds a good order and nobody is there to release it.

This is a 60 to 90 day pilot on a single line, cell, category or product family. The figures below are what the pilot measures against a baseline captured in its first two weeks. They are targets and instrumentation, not results already delivered.

• Expedite spend avoided. Counted against the baseline measured in weeks 1-2, on the single line or value stream chosen for the pilot.
• Orders stopped before commit. Every held order is logged with the rule that held it, so the number is auditable rather than asserted.
• A decision record for each action. Designed to give the buyer and the auditor the same view of why an order was placed or blocked.