Disruption Re-Planning Rebuild only the affected loads when execution breaks, with proof no constraint was violated
Load building and replenishment happen before the day starts. Re-planning happens during it. A trailer's cooling unit fails while it is staged, a road closes, a store pushes its receiving window, a tractor goes out of service. The committed plan is now partly wrong, and the dispatch office needs a corrected plan in seconds, not a full overnight re-optimization that reshuffles routes the drivers have already been briefed on.
This demo shows selective re-planning: given a baseline plan and a disruption, it rebuilds only the loads the disruption actually touches, proves that every other load is left exactly as it was, and re-verifies the whole new plan against the disrupted world. The live demo is at /grocery/replan.
What this demo proves
- Selective rebuild. Only loads affected by the disruption are re-planned. Everything else is carried over untouched.
- Byte-identical carry-over. The untouched loads are not re-optimized, re-sequenced, or re-serialized. They are the same objects, and the server asserts this before responding.
- Re-verification against the disrupted world. The changed loads are re-checked against the constraints as the disruption left them (the mutated network, not the original), so the certificate reflects the actual conditions the driver will face.
- Speed. A re-plan on this network completes in single-digit to low-tens of milliseconds because only a handful of loads are rebuilt.
The four disruptions
Each disruption is a small, honest mutation of the shared synthetic network or order book, applied to a deep copy so the core stays generic. The blueprint identifies which baseline loads the mutation affects, rebuilds just those with the verified Clarke-Wright load builder, and leaves the rest alone.
| Disruption | What changes in the world | Affected loads | Seed-42 weekday outcome |
|---|---|---|---|
Reefer failuretrailer_id |
That trailer loses its frozen and refrigerated compartments. Its cold lines must move; its ambient lines can stay. | The one load on that trailer. | Ambient lines stay on the trailer as an ambient-only load; the displaced cold lines rebuild onto another trailer. 18 unchanged, 1 modified, 1 added, about 0.4 ms. |
Store window closedstore_id |
That store's receiving window shrinks to afternoon-only, hours 4 to 8 after the 06:00 shift start. | Every load that visits that store. | For a store already served on its own short route, the tightened window is absorbed by waiting: 19 unchanged, 0 changes, about 2 ms. See the note below on why zero changes is correct. |
Road closureregion |
Travel to every store in that half-plane relative to the DC (north, south, east, or west) takes twice as long, modeled by pushing those stores to twice their distance from the DC in the copied network. | Every load touching a store in that region. | At weekday volume the routes are short enough to absorb the doubling: 19 unchanged, 0 changes, about 13 ms. At higher volume it forces real rebuilds (see below). |
Trailer downtrailer_id |
That tractor-trailer is removed from the fleet entirely. | The one load on that trailer. | Its load is rebuilt onto other capacity, and the downed trailer's id is never reused: 18 unchanged, 1 added, 1 stop moved off its original trailer, about 0.3 ms. |
When a disruption is absorbed with zero changes
Two of the seed-42 weekday cases above rebuild nothing, and that is the correct answer, not a bug. When a store's window shrinks to the afternoon but its load is a short single-store route, the driver simply arrives and waits until the window opens; the wait counts toward the hours-of-service duration, the arrival still lands inside the window, and the load the builder produces is identical to the original. The engine has proven the committed load is still legal under the tighter window, so there is nothing to change. Likewise, doubling travel time on a short route can still fit within the driver's hours, so the load survives verification unchanged. The demo reports this plainly: the plan is re-verified, found legal, and left alone.
The same disruptions force visible re-planning once the routes are longer and fuller.
On the holiday_surge scenario at seed 42 (43 baseline loads), a north road
closure yields 37 unchanged, 6 modified loads, and 7 stops relocated off their original
trailers in about 54 ms; closing the window on the multi-stop mega-store 3 yields
37 unchanged, 6 modified, 1 added, and 5 relocated stops in about 12 ms. Reefer failure
and trailer down always force a rebuild because a compartment or a whole trailer has
disappeared.
The untouched-is-untouched invariant
The response field unchanged_identical is a server-side assertion, not a
claim the client is asked to trust. Before responding, the blueprint canonicalizes each
carried-over load (trailer id, stop order, and lines) and confirms it hashes identically
to its baseline counterpart. The Disrupt and Plan Diff
tabs surface the result, and the diff explicitly lists the unchanged load ids as
unchanged_load_ids.
For a dispatch office this guarantee is operationally load-bearing. Drivers have already been briefed on their routes; picking has already been staged to those loads. "We re-planned trailer 6 and left the other eighteen exactly as briefed" is a very different conversation from "we re-optimized the whole board, please re-check every route." Selective re-planning means the correction is small, explainable, and easy to communicate to the floor.
Re-verification of the changed plan
Every rebuilt load is re-checked against all six load rules and issued a fresh certificate: temperature-zone integrity, payload weight, stacking safety, delivery windows, route duration against hours-of-service, and unload accessibility, each with its measured value and limit. The certificates the demo returns cover exactly the loads that changed; the ones that did not change already carry their baseline certificates.
On top of the per-load checks, the full new plan (untouched loads plus rebuilt loads) is run back through the plan-level verifier under the disrupted constraints. That check confirms two things: the plan is feasible (every load passes all six rules), and coverage is intact (every ordered line still appears exactly once across the plan, nothing dropped and nothing double-shipped). The Certificates tab shows this plan-level result alongside the per-load traces.
Determinism and statelessness
The demo holds no server session state between requests. The baseline is rebuilt
deterministically from the scenario name and seed on the server: the same
scenario and seed always produce the same network, the same
orders, and the same verified plan. The baseline endpoint returns that plan;
the client echoes it back with the disruption, but the disrupt endpoint
reconstructs the baseline of record itself from the scenario and seed rather than trusting
the echoed copy. That is what lets the byte-identical assertion be meaningful: it compares
the new plan against a freshly, deterministically rebuilt baseline, so a rehearsed
walkthrough at seed 42 reproduces exactly.
Reading the UI
Baseline
Pick a scenario and seed and build the plan. You get fleet and mileage KPIs, a route map (the red dot is the regional DC, grey dots are stores, amber dots are tight-dock stores, one colored polyline per trailer), a summary noting how many merges the engine rejected during building, and a card per load. Each load card shows three compartment fill bars (frozen, refrigerated, ambient) as a share of compartment cube, a payload weight bar, the stop list with simulated arrival times, and a pass/fail chip for each of the six rules.
Disrupt
Choose a disruption type and its parameter; the parameter dropdown is populated from the current baseline, so it only offers valid choices (trailers that actually carry cold lines for a reefer failure, stores that are actually visited, and so on). Inject it and the re-plan time in milliseconds is shown large, next to counts of untouched and rebuilt loads and the re-verification result, followed by a plain-language summary of what the re-planner did.
Plan Diff
A side-by-side of the baseline plan and the re-planned plan. Untouched loads are greyed and labeled; modified loads are outlined in amber; added loads in green. The map overlays the affected baseline routes as dashed grey lines and the re-planned routes as solid colored lines, so you can see exactly which stops moved and how the new routing differs from what was committed. A banner tallies unchanged, modified, added, and the number of stops relocated off their original trailer.
Certificates
The plan-level re-verification banner (feasible, all orders covered, untouched loads byte-identical) and then a full certificate for each changed load: all six rules enumerated with their pass/fail state, the human-readable detail sentence, and the measured value against the limit, plus the input hash and engine version. If a disruption was absorbed with no changes, this tab says so and points back to the plan-level proof that the plan is still legal.