Mock · synthetic data

Audit report
Ortelis Satellite

Ortelis is a fictional residential satellite internet operator. The report shows the look of a real audit, with five invented losses.

September 2026 · 5,000 orders · CAT + OMS + BPM + PROV · USD · run demo-20260901

This report is a mock. No engine generated it. The orders and numbers come from the invented dataset. It has the shape of the planned output (findings.json + journeys).
Findings 5 4 critical · 1 medium
Manual work 1,268 h per month, in the four systems only
Cost USD 57,319 per month, at USD 45 per loaded hour
Stuck orders 50 1% of the month, no later event

The revenue at risk from stuck orders adds up to USD 3,250 per month (50 × ARPU 65). The cost of R03 already includes it.

Executive summary

An order takes 69 hours. It should take less than one. Nobody works 60 of those hours: they are a gap between systems that no process owns.

Priority: add capacity_profile to the technical catalog (USD 18,750/month). Retry provisioning before the manual queue (USD 12,750/month). Compensate the 48-hour timer (USD 14,104/month). The three actions cover 80% of the cost.

Flow map

Each step happens in a different system. Dashed boxes mark where the order loses time or duplicates.

normal step manual wait gap with no event
Flow of one order across the catalog, OMS, BPM and provisioning The catalog validates the order. The BPM opens a manual capacity check. The OMS decomposes the order. The BPM installs. Activation fails in provisioning. The retry creates a second service order and then activates. Findings R01, R02, R03 and R04 are marked. CATALOG OMS BPM PROVISIONING Offer validated no capacity_profile R02 Manual check 2 h of manual work R02 Decomposition SO + WO in minutes Installation 6 h · 48 h timer R03 Activation fails HUB_TIMEOUT R01 Retry creates a 2nd SO R04 Active 60 h later 60 h

Source: data/demo/ (synthetic dataset). Arrows cross from one system to another. No common identifier joins them (R05). SO = service order. WO = work order.

State machine

The states of the order and three dead ends the audit found.

States of the order and their dead ends Normal path: order, validated, decomposed, scheduled, installed, provisioning, active. From decomposed, a retry creates a second service order. From provisioning, a failure without retry drops into a manual queue. A 48-hour timer without compensation leaves the order stuck. Order Validated Decomposed Scheduled Installed Provisioning Active 2nd service order R04 Failure, no retry R01 Uncompensated timer R03 Manual queuesomeone rescues it Stuckno later event With no common identifier, joining the four records requires a time window (R05).

A manual retry takes the order out of the queue. The timer does not. The 50 stuck orders stay in PROVISIONING at month end.

Where the days go

An order from the synthetic dataset, ORD-1005: 69 hours end to end. Nobody works 60 of them.

work by a system manual wait gap with no event
Timeline of ORD-1005 Two hours of manual check. Six of installation. One provisioning failure. Sixty hours with no event. A retry creates a second service order and activates the order. WORK WAIT NO EVENT 69 h end to end manual check · 2 h (R02) installation · 6 h HUB_TIMEOUT failure no event · 60 h (R01) retry + 2nd SO (R04) 0 h 12 h 24 h 36 h 48 h 60 h 69 h

The gap starts when the first attempt fails. It ends when someone retries by hand 60 hours later. In that interval there is no event: no declared wait and no scheduled retry.

Findings

The example shows five findings over the same month of orders. The severity will be derived from the impact.

Monthly impact calculated with the dataset rates: 5,000 orders, USD 45 per loaded hour.
ID Finding Severity Orders h/month USD/month Action
R01 Provisioning fallout with no retry Critical 400 · 8% 283 12,750 Retry automatically with backoff before the manual queue.
R02 Manual capacity check for a missing attribute Critical 5,000 · 100% 417 18,750 Add capacity_profile to the spec. Automate the beam assignment.
R03 The BPM timer expires without compensation Critical 150 · 3% 313 14,104 Close or requeue the order at 48 h. 50 orders ended up stuck.
R04 The OMS retry duplicates the service order Medium 20 · 0.4% 30 1,590 Retry idempotently, using the order key.
R05 No end-to-end correlation identifier Critical 300 · 6% 225 10,125 Use one common id in the four systems, from the order to the attempt.
Total 5,000 1,268 57,319

R03 includes USD 3,250 of revenue at risk. The evidence for each finding is in data/report.json (mock text in Spanish).