Business flow simulator

What decision is supported

How an order-to-cash process should respond when events arrive twice, late or not at all: which steps may retry automatically, which need a person, and what the queue looks like under each policy.

Who uses it

An operations analyst designing exception handling for a fictional distributor (Northwind Demo Supply), and an automation engineer who needs an audit trail for every retry.

What data enters

A scenario file describing suppliers, a manufacturer, a warehouse, retailers, a customer channel and a payment service, plus a seeded event schedule. Everything is authored and synthetic; no real orders, invoices or companies appear.

What is computed

A replay of typed events (purchase order, fulfilment, invoice, payment review, settlement, reporting) through a state machine with idempotency keys, a retry policy with bounded attempts, a manual review queue and an append-only audit log. Two policies can be replayed on the same schedule and compared.

What action is suggested

Accept the event, reject it as a duplicate, retry it with backoff, or route it to a review station, with the reason written to the log.

What evidence supports it

The lab counts what happened in the replay: events processed, duplicates rejected, retries and items sent to review. Those counts are computed in the browser from the synthetic replay and carry the label demo. No throughput, savings or accuracy figure is claimed.

No metric is claimed for this project. Anything computed by the repository on its synthetic fixture carries the label demo.

What fails or is uncertain

• The event schedule is authored, so the frequency of duplicates and delays reflects the scenario design, not any measured system.
• Settlement and reporting are modelled as single steps; real payment rails have more states than the demo shows.
• Policy comparison reports counts, not money, because no cost model has been validated against a real process.