Something breaks. Show which lines are at risk and when, price the recovery options against downtime avoided, verify every option is legal before offering it, and prove the rest of the plan was left alone.
Before any disruption runs, the inbound plan is built the way a planner builds it: each arrival is split into whole containers that fit one trailer on both cube and payload, then given the earliest dock slot inside the receiving window that still has a free door. All 16 combinations of scenario and plant produce a plan where every shipment passes all six rules. That matters because it means a rule failure in this demo is always caused by the disruption, never by a sloppy plan generator.
| Type | Models | What breaks |
|---|---|---|
| Supplier short-ships | Supplier ships part of the release quantity | Quantity, across every lane from that supplier inside 36h |
| Carrier breakdown | One in-transit shipment delayed | Timing, and the truck now docks off-schedule rather than in its booked slot |
| Customs hold | Cross-border inbound held at the border | Timing, across the whole cross-border population at once |
| Incoming inspection quarantine | Received stock fails inspection | On-hand only: physically on site, not usable |
| JIS sequence break | Sequenced cart arrives late and short | Sequence integrity, which stops the line even with parts on the dock |
A delayed truck keeps its real arrival time rather than being quietly re-snapped into the next
legal slot. That is deliberate: it lets the receiving_window rule catch an after-hours
arrival and say exactly how late it is, which is the honest picture. Re-snapping happens in recovery,
where it belongs.
For every part pushed to critical or at risk, four candidate moves are constructed as real shipments and run through all six rules before being offered:
A recovery that does not fit on a truck is not a recovery. Quantities are capped at whole containers fitting a single trailer, so a high-burn part gets less than the requested 24 hours of cover from one expedite. The option reports the hours it actually buys rather than the hours that were asked for.
Options sort by whether they remove downtime, then whether they are legal, then cost per downtime hour avoided. That last term is the decision a plant actually makes, and it regularly disagrees with raw cost: the cheapest option is often not the best value per hour recovered.
An option that lands after the line has already stopped cannot prevent the stop. The board says so in plain terms and still shows the downtime it removes, because "we are going down, the question is for how long" is a real and common answer.
Every shipment is canonicalized and SHA-256 hashed before and after. Shipments the disruption did not touch must hash identically, and that is asserted server side rather than claimed in the UI, so a drift raises instead of quietly shipping. The response reports counts of untouched, changed, added, and removed shipments.
diff = diff_plans(baseline_shipments, new_shipments)
assert all(base[k] == new[k] for k in untouched)Every response carries per-phase timings: disruption, clock recompute, full plan re-verification, diff, and recovery search. On a plant with roughly 600 inbound shipments, the whole cycle including re-verifying every shipment against all six rules runs in tens of milliseconds.
Synthetic data. Recovery costs are illustrative parameters, not benchmarked freight rates, so the dollar figures are useful for comparing options against each other and not for budgeting. No claim is made about predicting disruptions; this demo is about responding to one correctly once it is known.