Event-driven visibility for orders, shipments and stock: a design

1Context and motivation

An online order passes through many hands before it arrives: the order system, a warehouse, sometimes a consolidation hub and a line-haul carrier, customs, and a last-mile carrier. Each reports status in its own way. Many integrations still deliver that status as periodic files or snapshots, and each party defines states such as "shipped" or "delivered" slightly differently. The result is that the question "where is this order, and will it arrive on time?" is answered late, or inconsistently.

Visibility is widely assumed to improve supply chain performance, but it has been an ill-defined concept; in a study of five external linkages in retail supply chains, the level of visibility differed considerably across linkages, driven by both technology and non-technology factors¹. The information exchanged in supply chains includes inventory, sales, demand forecasts, order status and production schedules, and it can be shared through direct transfer, a third party, or an information hub². A commerce platform that connects merchants, warehouses and carriers is placed to act as such a hub.

This paper describes the design we propose for that hub's core: a service that turns status reports into events, keeps the current state of every order, package and stock position, and runs detection and prediction on top. An earlier version of this paper reported simulated comparisons of batch and event-driven visibility that we cannot show, and regional findings without a source; both are removed.

A caution from the literature frames the work. In one numerical study, sharing demand and inventory data lowered supply chain costs by 2.2% on average, while halving lead times lowered them by 21%³. Visibility is worth building only if it changes what happens to the goods.

2Design principles

• One event vocabulary. Every input is translated into a canonical event with defined semantics before anything else uses it.
• Event time, not arrival time. Events are ordered by when they happened, and late or duplicate events are handled explicitly.
• State is derived and replayable. The current state of an entity is computed from its events and can be recomputed when logic changes.
• Uncertainty is shown. Arrival-time predictions are distributions; low-visibility legs are labelled as such.
• Visibility leads to action. Each detector has a defined consumer: order routing, a customer message, or an operator queue.

3Architecture

3.1Canonical event schema

The schema follows the structure of the GS1 EPCIS standard, which enables disparate applications to create and share visibility event data within and across enterprises⁴. Each event records what entity it concerns (order, package, line item, stock batch), when it happened and when it was received, where it happened (node, carrier facility, region), and why (a business step and, for exceptions, a reason code). Entities have a defined state machine (for example created, allocated, picked, packed, handed over, in transit, at customs, out for delivery, delivered, return requested, return received), and an event is valid only if it is a permitted transition from the entity's current state. A "delivered" event for a package that was never handed over is held for review rather than applied.

3.2Ingestion and normalisation

Carriers and partners send events by webhook where they can and by file where they cannot. Connectors map each source's codes to the canonical schema; unmapped codes go to a review queue rather than being guessed. Each event receives a deduplication key derived from its source identifier and content, so that a resent file does not create a second scan.

3.3Stream processing by event time

Carrier events arrive out of order and sometimes hours late. Stream processing over unbounded data has to accept that it never knows whether all the data for a period has arrived; the dataflow model separates event time from processing time and makes the trade-off between correctness, latency and cost an explicit choice⁵. In our design each derived metric (dwell time at a facility, time since last scan) is computed by event time, with watermarks that decide when a window is treated as complete and rules for revising a result when a late event arrives. Events are kept in an append-only log, and every derived view can be rebuilt from it⁶.

3.4State store

The state store holds the current state of each order, package and stock position, derived from the event log. The literature distinguishes a digital model, a digital shadow and a digital twin by their level of integration with the physical system, and finds work on full digital twins scarce⁷; we use the plainer name "state store" because the service observes the physical flow and recommends actions, but does not control it directly.

Some legs report rarely: a container at sea or a package with a carrier that scans only at pickup and delivery. Between reports, the state store estimates position and expected progress from the last known state and the lane's historical transit distribution. Estimating the state of a dynamic system from noisy, incomplete observations is the filtering and prediction problem, which Kalman treated with a state-transition method of analysis of dynamic systems⁸. We use the same structure in a simpler form: a prior from the lane's history, updated at each event.

3.5Detection

Detectors watch for deviations: no scan within the expected interval for a lane, dwell time at a facility beyond its usual range, a carrier whose event rate drops while its volume does not, a cluster of packages held at customs on one lane. Anomaly detection techniques differ in what they assume normal behaviour looks like, and those assumptions decide which technique suits which signal⁹. Each detector here has a stated assumption (for example, scan gaps per lane follow their trailing distribution) and a stated consumer.

3.6Arrival-time prediction

For each open shipment the service predicts a distribution of arrival time and updates it at each event. Distributional delivery-time forecasts with a cost-sensitive rule for choosing a promised day have been developed and tested on JD.com data¹⁰. Arrival times computed from a planned route are unreliable when the route actually taken is not known in advance, and a residual network that post-processes the route-based estimate improved accuracy in offline experiments and online tests at Uber¹¹. Our design follows that structure: a baseline from the lane and carrier, refined by a learned correction that uses the shipment's event history.

3.7Consumers

Order routing reads node and carrier health to steer new orders away from a failing lane. Customer messaging reads predicted arrival and its uncertainty to update the date a customer sees. Operations staff receive a queue of at-risk shipments ranked by predicted lateness and order value. Merchants see the state and the predicted arrival for their own orders.

Component	Problem it addresses	Evidence
Canonical event schema (what, when, where, why)	Each source means something different by each status	4, 2
Event-time processing with watermarks	Late and out-of-order carrier events corrupt metrics	5
Append-only log, replayable state	Derived status cannot be corrected or audited	6
State estimation between sparse reports	Legs with few scans look frozen	8
Detectors with stated assumptions	Delays found only after the promise is missed	9
Distributional, updating arrival-time model	Static lane estimates mislead under variable conditions	10, 11
Defined consumer per signal	Dashboards that show problems but change nothing	3, 1

Source: our design, with the works cited in the table.

4A worked model of detection lag

How quickly a stalled shipment can be detected depends on how often its status is refreshed. Suppose a detector flags a shipment when it has had no scan for 4 hours beyond its lane's usual interval. Under periodic batch updates every T hours, the stall becomes detectable 4 hours after it starts, and is then seen at the next batch, on average T / 2 hours later if the stall's start is uniformly distributed within the batch cycle.

Update mode (input)	Expected detection lag (hours, computed)
Batch every 24 hours	4 + 12 = 16.0
Batch every 12 hours	4 + 6 = 10.0
Batch every 1 hour	4 + 0.5 = 4.5
Event updates, 0.1 hour ingestion delay	4 + 0.1 = 4.1

Source: Worked model; inputs in the table.

For a shipment with a two-day promise, the difference between 16 hours and about 4 hours is the difference between learning of a stall with a day left and with a day and a half left. The table also shows that once updates are hourly, the threshold dominates: past that point, faster detection comes from better detectors, not from faster feeds. The model assumes the stall leaves no earlier trace; a detector that recognises slowing scans before they stop would do better.

5Customer communication, privacy and fairness

Telling customers more is not automatically better. In archival data from an online retailer, a fulfilment delay was followed by lower order frequency and smaller orders from loyal customers¹²; an honest revised date may limit that damage, but that is untested here. In field and laboratory experiments in food service, letting customers observe operational processes raised perceived value and service quality¹³; whether a similar effect holds for parcel tracking is an open question. The design therefore shows predicted dates with their uncertainty and labels low-visibility legs, and treats the effect on trust as something to measure.

Scan and location data can reveal patterns about warehouse and delivery workers. The service keeps event data at the level of packages and facilities, does not ingest driver-level location, limits granular data to roles that need it, and sets retention per region. Customer tracking pages show status and an area, not a precise location. When operators prioritise interventions, the ranking rule is written down and its effect by region and merchant size is reported.

6Evaluation protocol

Before any claim about detection or arrival-time accuracy, a deployment would need to measure: detection lag against the time a stall began, reconstructed from complete event logs; the precision of each detector (the share of alerts that were real delays); arrival-time error and calibration of the predicted intervals by lane and carrier; and, for each consumer, whether the action taken (rerouting, a revised date, an operator call) changed delivery or contact rates, in a pre-registered comparison.

7Limitations

• No measurements. We have not measured detection lag, prediction accuracy or customer effects for this design.
• Partner data limits. The service is only as good as what partners send; some legs will stay low-visibility, and some carriers will only send files.
• Mapping errors. Translating partner codes into canonical events is error-prone, and a wrong mapping is worse than a missing one.
• Regional claims removed. The earlier version characterised carrier integration quality by continent without a source. Those claims are cut.
• Upstream production. Supplier and factory events are out of scope in this version.
• Worked model only. Table 2 shows a bound set by update frequency, not a measured improvement.

8Conclusion

We have described a visibility service built on a canonical event schema, event-time processing, a replayable state store, detectors with stated assumptions, and an updating arrival-time model, each output tied to a consumer that acts on it. Each part rests on published work summarised in Table 1, and Table 2 shows how update frequency bounds detection. The next step is to reconstruct detection lag and arrival-time error from complete event logs on a small set of lanes and report them with the method stated.