Find your next learning step
A smaller scenario set can make capacity optimisation tractable, but compression is defensible only when probability transfer, tail events and the resulting decision remain visible.
Open the chapter contents · Queueing Theory root · Gold Standard of Education · How X Works
Chapter contents
Choose the route closest to the question, or read from Chapter 1 for the complete argument. The chapters remain open on the page; these grouped routes are an index.
Route 1 · Define the reduction
Route 2 · Work the scenario ledger
Route 3 · Test decisions and transfer
Route 4 · Check limits and evidence
Route 5 · Ask and continue
CHAPTER 1 OF 12 · DEFINE THE REDUCTION
1. Why a smaller scenario set can change the decision
Capacity models often begin with hundreds or thousands of demand paths. Scenario reduction replaces that large empirical distribution with fewer representative paths and new weights. The computational gain can be real, but the reduced set is not a neutral summary. It changes which futures the optimiser is allowed to see.
The practical question is therefore not simply, “Are the retained paths close to the originals?” It is, “Does the reduced distribution preserve the decisions, tail failures and timing patterns that matter?” Dupačová, Gröwe-Kuska and Römisch formalised scenario reduction through probability metrics. That gives a principled starting point, not permission to ignore operational consequences.
CHAPTER 2 OF 12 · DEFINE THE REDUCTION
2. The object being reduced
A scenario is a whole path ξᵢ=(Aᵢ1,…,AᵢT), not one isolated forecast. It carries probability pᵢ. A reduction chooses a retained index set J, removes the other paths and transfers their probability to retained neighbours. The new weights must remain non-negative and sum to one.
Distance must match the decision. Euclidean distance across raw arrivals may be sensible when every horizon has comparable scale. It can be misleading when a late surge is far more costly than an early lull, or when ramp limits make consecutive changes decisive. Scaling, horizon weights and feature choice belong in the model record.
CHAPTER 3 OF 12 · WORK THE SCENARIO LEDGER
3. A six-path capacity ledger
Suppose a service has two planning periods and can process 10 jobs per period. A second server adds 6 per period but costs 18 units to activate. Unserved jobs cost 4 each. The original paths are below.
| Path | Arrivals (period 1, period 2) | Probability | No extra server shortfall | Cost if no extra server |
|---|---|---|---|---|
| A | (8, 9) | 0.30 | 0 | 0 |
| B | (10, 11) | 0.25 | 1 | 4 |
| C | (12, 13) | 0.20 | 5 | 20 |
| D | (7, 18) | 0.10 | 8 | 32 |
| E | (16, 8) | 0.10 | 6 | 24 |
| F | (20, 20) | 0.05 | 20 | 80 |
The expected shortfall cost without the extra server is 0.25×4 + 0.20×20 + 0.10×32 + 0.10×24 + 0.05×80 = 14.6. On expected cost alone, paying 18 is unattractive. Yet Path F creates 20 unserved jobs and may breach a service limit. The tail decision can differ from the expected-cost decision.
CHAPTER 4 OF 12 · WORK THE SCENARIO LEDGER
4. Forward selection and probability reassignment
One common idea is to retain paths that minimise a probability-metric discrepancy. If A, C and F are kept, probability from B may move to C, D may move to C, and E may move to F under a chosen distance. The reduced weights become sums of the original probabilities assigned to each representative.
That reassignment is visible evidence. A table should show every removed path, its representative, the distance and the transferred mass. A reduced scenario with weight 0.35 is not observed 35% of the time; it may stand for several distinct histories. Interpret it as a modelling representative, not a literal frequency.
CHAPTER 5 OF 12 · WORK THE SCENARIO LEDGER
5. Tail preservation is a separate requirement
A metric that minimises average transportation distance can sacrifice a rare extreme if it is far away but has low probability. That can be unacceptable when the decision is driven by a maximum-delay constraint, a chance constraint or conditional tail loss.
For the ledger, deliberately force F into the retained set, or stratify the scenarios before reduction so the upper-tail stratum keeps representation. Then compare tail quantities before and after: probability of any shortfall, 95th-percentile shortfall, expected shortfall above a threshold, and the identity of binding horizons. “Close on average” is not a tail certificate.
CHAPTER 6 OF 12 · TEST DECISIONS AND TRANSFER
6. Decision-stability check
Run the planning model on both distributions. Record the chosen capacity, objective value under the reduced distribution, and—most importantly—the reduced decision evaluated on every original scenario. This out-of-reduction evaluation prevents a compressed model from grading its own homework.
| Check | Full set | Reduced set | Reduced decision on full set |
|---|---|---|---|
| Extra server selected | No | No | No |
| Expected shortfall cost | 14.6 | 13.8 | 14.6 |
| Worst shortfall | 20 | 20 | 20 |
| Probability shortfall exceeds 10 | 0.05 | 0.05 | 0.05 |
If a small change in retained paths flips the capacity decision, the decision sits near a boundary. Report that instability instead of choosing the most convenient reduction.
CHAPTER 7 OF 12 · TEST DECISIONS AND TRANSFER
7. Changed-context transfer: ramped capacity
Now suppose the second server needs one period to become ready. Paths D and E no longer have interchangeable consequences: an early surge can trigger capacity for period 2, while a late surge may arrive before the server is useful. A distance based only on total arrivals treats D=(7,18) and E=(16,8) as equally large totals, but the timing creates different actions.
The transfer check is to repeat reduction with a path-aware distance, then compare start-time decisions. Preserve adjacent-period changes, peak timing and readiness state. This connects directly to joint quantile scenarios and feasible capacity paths, where marginal forecasts cannot substitute for coherent paths.
CHAPTER 8 OF 12 · TEST DECISIONS AND TRANSFER
8. Validation without a false gold standard
Split scenario construction from evaluation when possible. Use one sample to build and reduce scenarios, then evaluate the resulting decision on held-out or newly simulated paths. Repeat the reduction across seeds or bootstrap samples. Record selection frequency for each representative and distribution of decision regret.
Regret here means the cost of using the reduced-set decision on an evaluation path minus the cost of the best decision available under the same information. It must use the same feasibility rules and cost definition. Negative or inconsistent regret usually signals mismatched evaluation logic.
CHAPTER 9 OF 12 · CHECK LIMITS AND EVIDENCE
9. Limits and common misconceptions
Scenario reduction does not repair a biased forecast generator. It cannot invent a tail never simulated, fix a wrong dependence structure or make probability estimates reliable with too little data. A low metric discrepancy need not imply stable integer decisions because discrete optima can jump at boundaries.
Do not confuse fewer scenarios with less uncertainty. The uncertainty remains; only its computational representation changed. Do not preserve extremes without their plausible probability, and do not assign a removed path to a representative across an operational discontinuity merely because raw vectors are close.
CHAPTER 10 OF 12 · CHECK LIMITS AND EVIDENCE
10. Practical evidence checklist
Keep the original scenario generator, units, horizon and probability normalisation. Save the distance definition, scaling, reduction algorithm, random seed, retained IDs and reassignment matrix. Report metric discrepancy, runtime, objective gap, tail diagnostics and full-set evaluation of the reduced decision.
For a production decision, add sensitivity runs over retained-set size and tail rules. A defensible stopping point is where more scenarios no longer change the action materially and the residual evaluation uncertainty is acceptable for the decision—not where a chart first looks smooth.
CHAPTER 11 OF 12 · ASK AND CONTINUE
11. Frequently asked questions
How many scenarios should remain?
There is no universal number. Increase the retained count until decisions, tail checks and held-out performance stabilise within declared tolerances. Computational budget is a constraint, not an accuracy argument.
Must the rarest scenario always be retained?
No. Retain or protect it when it is plausible and decision-relevant. An impossible data error should be corrected at the generator, while a plausible catastrophe may deserve explicit stress treatment even if its probability is uncertain.
Can clustering replace scenario reduction?
Clustering can create representatives, but its objective may not preserve probability metrics or decisions. Validate it with the same reassignment, tail and full-set decision checks.
CHAPTER 12 OF 12 · ASK AND CONTINUE
12. Sources and next reading
The primary foundation is Dupačová, Gröwe-Kuska and Römisch, Scenario reduction in stochastic programming, with Heitsch and Römisch, Scenario reduction algorithms in stochastic programming, for algorithmic development. These sources justify probability-metric reduction; the worked ledger and operational checks above are original teaching examples.
Continue through the Queueing Theory root, then revisit joint quantile scenarios and quantile crossing and monotone capacity actions. The Gold Standard of Education explains why changed-context checks matter, while How X Works connects the method to other systems.
Top · Contents · Previous · How X Works