A supplier promise is not a recovery plan

A customer needs 120 units. The supplier now promises forty on time and eighty later. The destination warehouse has thirty units available after existing reservations.

The buyer has a fifty-unit gap. Summarizing the supplier's message does not tell them which customer commitment is exposed, whether another warehouse can help or who may approve the cost.

The supplier disruption workbench connects those steps. It preserves the original message, calculates what can arrive in time, presents a recovery option and records the approved actions through source read-back. The example is synthetic, including the supplier, warehouses and approval limits.

Archive date: 20 August 2026. Implementation and evidence reviewed on 24 October 2026; the archive date does not date the experiment.

Count usable supply before proposing recovery

The destination warehouse physically holds forty units, but ten are reserved elsewhere. Thirty remain eligible. Add the supplier's forty timely units and the plan covers seventy of the 120 required units.

The eighty late units cannot cover demand by its deadline. The supplier's revised promise also replaces the old schedule. Counting both would invent supply.

Another warehouse has fifty eligible units of the same item. A transfer would cover the gap for EUR 160, above the buyer's EUR 100 limit. The workbench names the procurement manager as the next decision-maker and shows the records behind the calculation.

Actual app capture of synthetic case C-01, cropped to assessment and demand. Demonstration mode uses structured input and fixture adapters; no extraction or model call.

Use the agent where the input needs interpretation

A structured schedule can go straight through validation. An email may contain a correction, an ambiguous date or packaging quantities that are easy to mistake for the ordered units.

The LangGraph agent reads the stored message and permitted purchase-order records, then proposes cited terms or pauses for clarification. Its five fixed tools cannot approve spending, send email or write an ERP record. Every proposed field must survive schema and evidence checks before entering assessment.

The division is practical: the model interprets prose, while deterministic code calculates quantities, dates and eligibility. If a message does not establish a year or a firm quantity, a visible question is more useful than a confident guess. Questions remain unsent drafts; a recorded reply or cited correction creates a new assessment.

Approve the exact plan

The review binds the proposed terms, source versions and plan cost. A buyer cannot authorize the EUR 160 transfer by selecting a different role in the interface. The API checks its own authority records and refuses the attempt.

Review-panel crop from the same structured synthetic demonstration. Simulated roles and fixture sources; no model call.

Approval also does not freeze remote systems. Before claiming an action, the workflow rechecks relevant authority and source conditions. Source write preconditions still matter because the read and the later write are not one remote transaction.

Treat a lost response as unfinished work

The demonstration applies three distinct actions: amend the purchase order, reserve stock and request a transfer. Each has a durable operation identity and journal entry.

Its reservation succeeds, but the response is deliberately lost. The application records an unknown outcome, then looks up that same operation before continuing. It finds the existing reservation instead of creating another one. Final verification reads the changed records back from their sources.

Synthetic recovery after a lost reservation response, using fixture adapters and no model. The framed crop distinguishes verified records from physical arrival.

The Next.js interface, Fastify API and queue worker share one application container, with PostgreSQL separate. The API runs the extraction graph and owns business writes; the worker advances queued jobs. This makes the local workflow reproducible while keeping model latency in the API's failure boundary. Architecture.

What the evidence supports

An early untouched email set produced only 6 correct outcomes from 10 cases. After changes, a separate author created a new 16-case set. On its single live run, Claude Haiku 5.5 selected the expected proposal-or-pause outcome in all 16 cases and extracted all 84 required fields across the ten proposal cases. The simple baseline reached 6 of 16 outcomes. Evaluation history and later report.

That later result is promising for email interpretation. Five model proposals reached the seeded PostgreSQL workflow; other proposals were checked in memory. One downstream mismatch was shared by the oracle-input run and attributed to the seeded world. The evaluation did not exercise approval, purchasing or delivery. It is one synthetic set, not a production accuracy estimate.

Separately, the public snapshot's verification record reports 630 unit tests, 508 integration tests and 66 packaged checks passing, with no model call. Historical live evaluations remain distinct from those snapshot checks.

The repository includes a no-key demo. Its ERPNext connector is an isolated sandbox proof, not the application's purchasing backend, and cannot perform the full split-delivery workflow. Physical receipt, real supplier authentication and customer benefit remain unverified. The useful demonstration is a buyer's ability to trace a changed promise through a specific plan, an authorized decision and the records changed afterward.