Resilience as an explicit objective in fulfilment orchestration under supply disruptions: a design

1Context and motivation

Port closures, carrier strikes, factory shutdowns, sanctions and extreme weather interrupt the physical flows that online orders depend on. The cost of such interruptions is not only operational. In a sample of 827 disruption announcements made between 1989 and 2000, the average abnormal stock return of the affected firms was nearly minus 40% over the period from one year before to two years after the announcement, and firms did not recover quickly¹.

Order routing and stock positioning are usually tuned for cost and average lead time in normal conditions. That tuning tends to concentrate stock in a few central nodes and flows on a few cheap lanes. Concentration has a real benefit: pooling demand from several locations lowers expected holding and shortage costs². It also has a cost that the usual objective does not see: case-based research relates the severity of a disruption to the density and complexity of the supply chain and to the criticality of its nodes, and questions supply base reduction and sourcing from clusters on those grounds³.

This paper describes how we propose to make resilience an explicit objective of an orchestration service that assigns orders to fulfilment nodes and moves stock between them. An earlier version of this paper reported simulated comparisons between efficiency-first and resilience-aware orchestration; we cannot show those simulations, and they are removed. What remains is the design and the published work it rests on.

2What the literature establishes

Four findings shape the design.

• Disruption risk is distinct from coordination risk. Supply chain risk divides into the risk of matching supply with demand and the risk of disruption to normal activity, and managing the second needs joint risk assessment and risk mitigation⁴. A reliable forecast does not make a network resilient.
• Structure matters more than any single node. A failure at a node or arc does not necessarily become a network-level disruption; network structure strongly affects the likelihood of disruption, and different structures have different levels of resilience⁵.
• Complexity raises risk. As supply chains become more complex through global sourcing and leaner operation, supply chain risk increases, and the response is to manage and mitigate it by building more resilient supply chains⁶. The operations research literature on disruptions covers evaluation, strategic decisions, sourcing, contracts, inventory and facility location⁷.
• The right mitigation depends on the kind of disruption. For a firm with one unreliable and one reliable but more expensive supplier, a supplier's percentage uptime and whether disruptions are frequent and short or rare and long determine which strategy is optimal; sourcing mitigation is increasingly favoured over inventory as disruptions become rarer but longer, and contingent rerouting is often part of the optimal strategy when the backup can ramp up⁸.

3Design principles

• Resilience is a measured objective. Each policy reports performance under named disruption scenarios next to its cost in normal conditions.
• Impact before probability. Rank exposures by what a loss would do before trying to estimate how likely it is.
• Mitigation is a portfolio. Inventory, alternative sources, flexible capacity and contingent rerouting are separate options with separate costs.
• Conservatism is a parameter. How much protection to buy is an explicit setting with a visible price, not a hidden safety factor.
• Scarcity rules are written down. Who is served first when stock is short is a policy approved by people, not an accident of the optimiser.

4Architecture

The resilience functions extend an orchestration service that already makes order-level decisions in seconds, inventory moves in hours to days, and network signals over weeks to months. Each horizon gains a resilience component.

4.1Disruption detection

The service watches lead times, scan gaps, failure rates and throughput per node, carrier and lane, and flags deviations from their recent distribution. Anomaly detection techniques differ in what they assume normal behaviour looks like, and those assumptions decide which technique suits which signal⁹. In our design a lead-time series per lane uses a distribution-based detector; carrier event streams use a rate-based detector; both feed a disruption record with a type (node, carrier, corridor), a start time and an estimated scope. External alerts from carriers and ports enter the same record when available.

4.2Exposure model

Low-probability, high-impact risks are hard to predict and quantify. In a three-year engagement with Ford, Simchi-Levi and colleagues built a risk-exposure model that assesses the impact of a disruption anywhere in the supply chain and defers estimating its probability until after its effect is known, which let the company find previously unrecognised exposures and plan contingencies even when the duration of a disruption was unknown¹⁰. We adopt that order of work. For each node and lane, the exposure model computes the demand that would go unserved if it were lost for a given recovery time, after accounting for stock on hand and the capacity of alternatives (Table 2). Probabilities are attached afterwards, where there is data to support them.

4.3Mitigation portfolio

The service chooses among four kinds of mitigation, guided by the disruption profile each is suited to⁸.

• Inventory. Extra stock for critical items at exposed nodes, sized against the recovery time of the disruption it covers. Suited to frequent, short disruptions.
• Alternative sources and lanes. Qualified second sources or lanes held ready. Suited to rare, long disruptions.
• Flexible capacity. Nodes able to fulfil items outside their usual range. Limited flexibility, configured to chain products and plants together, yields most of the benefit of total flexibility¹¹. We apply the same principle to fulfilment nodes: each node can fulfil a few categories beyond its own, arranged so that the categories form a chain.
• Contingent rerouting. Pre-computed rerouting plans that switch orders to backup nodes and carriers when a disruption is detected.

4.4Robust order and inventory decisions

During a declared disruption, order assignment and rebalancing solve their usual problems with uncertain lead times and capacities. Robust linear optimisation accepts a solution that is worse at nominal values in exchange for one that stays feasible when the data change, and the level of conservatism can be adjusted through probabilistic bounds on constraint violation, keeping the robust problem linear¹². The conservatism setting is the "how much protection" parameter in the design principles, and it is reported with its cost.

4.5Reliable positioning

The same idea applies to where stock is held. Classical location models assume chosen facilities always operate; reliability models add the expected cost of serving customers from more distant facilities after a failure, and trade-off curves between operating cost and expected failure cost often show substantial reliability gains for small increases in operating cost¹³. The network-horizon component produces such trade-off curves for the current stock positions, and flags positions where a small change buys a large reduction in exposure.

4.6Scenario testing

Policies are tested against named scenarios before they are needed: loss of a node, closure of a corridor, loss of a carrier, a regional demand surge. Simulation has been used to study how an epidemic outbreak propagates through a global supply chain¹⁴; our scenario harness replays logged demand against the network with the scenario's capacity changes applied.

4.7Allocation under scarcity

When stock or capacity is short, some orders wait. The design makes the allocation rule explicit: a minimum service share per region and per merchant tier, chosen by an operator. Fairness rules cost efficiency, and for proportional and max-min fairness that loss has a tight characterisation across a broad family of allocation problems¹⁵; the service reports it alongside each rule.

Component	Problem it addresses	Evidence
Disruption detection on lead times and event rates	Disruptions noticed only when promises are already broken	9
Impact-first exposure model	Probabilities of rare events are unknown	10
Mitigation chosen by disruption profile	One mitigation applied to every kind of risk	8
Chained limited flexibility across nodes	Full flexibility is expensive; none is fragile	11
Adjustable robust optimisation	Plans that fail when lead times or capacities change	12
Reliability-aware positioning	Concentrated stock creates critical nodes	13, 3, 2
Explicit allocation rule with reported cost	Implicit prioritisation during scarcity	15

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

5A worked exposure calculation

Table 2 applies the impact-first exposure model to four hypothetical nodes for one scenario: each node is unavailable for 21 days. Days of cover combine stock that is not at the failed node and spare capacity at alternative nodes that can serve the same demand.

Node	Daily demand served (units, input)	Days of cover (input)	Recovery time (days, input)	Unserved units (computed)	Rank
N1	400	10	21	400 x 11 = 4,400	1
N2	250	14	21	250 x 7 = 1,750	3
N3	600	30	21	0	4
N4	100	3	21	100 x 18 = 1,800	2

Source: Worked model; inputs in the table.

The ranking differs from a ranking by volume. N3 serves the most demand but has cover beyond the recovery time, so its loss leaves no demand unserved in this scenario. N4 serves a quarter of N1's volume but ranks second because it has almost no cover. Mitigation spending would start with N1 and N4. The calculation treats nodes independently; a network model, such as the linear program in the cited work, would capture alternatives that are themselves shared between nodes.

6Evaluation protocol

Before any claim about resilience could be made, a deployment would need to show, per scenario: the share of orders delivered within the promise during the disruption, the time to return to the pre-disruption level, and the cost of the mitigation held in normal periods. These would be measured first in scenario replay against logged demand, then compared against real disruptions as they occur, with the exposure ranking checked against which nodes actually caused unserved demand.

7Ethics and governance

During a disruption the service decides whose orders wait. The allocation rule, its cost and the regions and merchant tiers it affects are logged and reviewed after each event. Rerouting and rushed transfers change work in warehouses and carriers; the design caps how often a node's plan can change within a shift. Customers and merchants affected by a disruption are told that delivery dates have changed and why, in plain terms. Operational data about partners is used for detection and planning, under access controls, and is not shared with other partners.

8Limitations

• No measurements. We have not measured how this design performs in a disruption. The figures quoted from the literature describe other firms and settings.
• Detection lags. A detector needs data after a disruption starts; for slow-onset events, the first signal can arrive late.
• Exposure inputs are estimates. Recovery times are scenarios, not forecasts, and the independent-node calculation in Table 2 ignores shared alternatives.
• Upstream risk. The design acts on stock and flows the service controls. Supplier financial health and sub-tier suppliers are outside its view.
• Regional generalisation. The earlier version described disruption patterns by continent. We removed those claims; they had no source.
• Cost of protection. Every mitigation has a cost in normal periods. The design makes that cost visible; it does not decide how much protection a business should buy.

9Conclusion

We have described resilience as an explicit objective of fulfilment orchestration: disruptions detected from telemetry, exposures ranked by impact before probability, mitigation chosen by the profile of the disruption it covers, robust decisions with adjustable conservatism, and allocation rules written down with their cost. Each part rests on published work summarised in Table 1. The next step is to build the scenario replay on logged demand and report the exposure ranking and its check against real events.