What do you optimise when the data isn't known yet?
Topic 08 solved the shortest path under a quiet assumption: choosing an edge means taking it. Topic 20 removes that assumption on the same network, and topic 22 removes the assumption that the numbers are known before you commit; the two honest ways to cope (average over what might happen, or armour against the worst of it) give different answers on the same problem. Topic 09 is the mathematics of waiting when arrivals and service are random.
Real decisions are made before the facts are in. You order stock before you know demand, commit generating capacity before you know the wind, set a budget before you know the exchange rate. The naive move (take the average of each unknown, treat it as certain, solve the deterministic problem) is Flaw of Averages territory: it systematically misprices risk, because a plan that is fine on average can still be a disaster on the outcomes that actually matter. The figure above shows it directly, and topic 04's rounding trap and topic 18's northwest-corner trap were smaller versions of the same lesson: feasible-looking is not good.
There are two disciplined ways to handle the gap, and they answer different questions.
Stochastic optimisation assumes you have a probability distribution over what might happen, and minimises expected cost (or maximises expected value). The standard shape is two-stage with recourse: choose a here-and-now decision x now, watch the random outcome ξ land, then take a corrective wait-and-see decision y(ξ). You are optimising x against the average cost of the best possible correction. This is the right frame when you trust your probabilities and you will face the situation many times, so the average is what you actually experience.
Robust optimisation refuses to name probabilities. It takes an uncertainty set (a range each unknown could lie in) and optimises the worst case over that set. The answer comes with a hard guarantee: whatever happens inside the set, you do at least this well. That is the right frame for a decision you make once, where a single bad outcome is unacceptable and you would rather not bet the business on a distribution you had to guess.
Two-stage stochastic program. With first-stage decision x, cost vector c, random data ξ with distribution P, and a recourse cost Q(x, ξ) equal to the optimal second-stage response:
minimise cᵀx + E_ξ [ Q(x, ξ) ]
Q(x, ξ) = min { qᵀy : W y = h(ξ) − T(ξ) x , y ≥ 0 }
Founded by Dantzig (“Linear Programming under Uncertainty,” Management Science 1, 197–206 (1955)) and Beale the same year; the reference text is Birge & Louveaux, Introduction to Stochastic Programming (Springer, 2nd ed., 2011). Two quantities score how much the uncertainty is costing you, and both are visible in the figure: the expected value of perfect information (EVPI) is what you would pay for a perfect forecast. Here 120 − 80 = 40, and the value of the stochastic solution (VSS) is what the full stochastic (recourse) model earns over the lazy plug-in-the-mean model. Here 80 − 70 = 10; both quantities are non-negative by construction. A large VSS is, in practice, what justifies the extra modelling effort.
The newsvendor, the one-line case everything reduces to: order Q, demand D random, underage cost Cu per unit short, overage cost Co per unit unsold. Expected cost is convex in Q, and setting its derivative to zero gives the critical-fractile rule:
order Q* = smallest Q with F(Q) ≥ Cᵤ / (Cᵤ + Cₒ)
F = cumulative distribution of demand
Here Cu = 5 − 2 = 3, Co = 2 − 0 = 2, the ratio is 0.6, and the smallest Q with P(D ≤ Q) ≥ 0.6 is 60, which the script confirms is the exact argmax of expected profit over the whole grid. This same fractile returns in topic 24 as the service level behind safety stock, and it is exactly the rule airlines use to protect seats for late-booking full-fare passengers.
Robust counterpart. Replace “minimise cost” with “minimise the maximum cost over ξ in an uncertainty set U.” Soyster (1973) gave the first version: box uncertainty, famously over-conservative. Ben-Tal & Nemirovski (Mathematics of Operations Research 23, 769–805 (1998)) showed an ellipsoidal U keeps a linear program solvable as a second-order cone program: tractable, not just definable. Bertsimas & Sim (“The Price of Robustness,” Operations Research 52(1), 35–53 (2004)) added a budget parameter Γ that dials how many unknowns may go bad at once, so you can buy exactly as much protection as you want and read off its cost in lost objective. On the figure's instance the max-min order is 20, guaranteeing profit 60; the stochastic order 60 expects 80 but risks −20. The 20 you give up is the literal price of the guarantee.
Keeping the lights on, every day Grid operators solve unit commitment a day ahead (which generators to switch on) before they know tomorrow's demand or wind and solar output. Cast as a two-stage stochastic program: commit plants now (first stage), redispatch against whatever the weather actually does (recourse), minimise expected cost subject to a feasible response in every scenario. It is a canonical application and an active research and pilot area. In day-to-day operation most system operators still run deterministic unit commitment hedged with reserve margins; scenario-based stochastic versions are so far deployed only in limited settings.
And on the quantum side of this page A robust-control pulse is a gate designed to hold its fidelity not at one nominal set of hardware parameters but across a whole band of them: a detuning that could drift, a control amplitude that could be miscalibrated. That is robust optimisation in its exact form: an uncertainty set of Hamiltonian parameters, and a pulse chosen to maximise worst-case fidelity over the set. It is why DRAG and its descendants exist, and it is the same worst-case-over-a-set instinct that topic 20's reinforcement-learning gate design (Baum et al., Q-CTRL, 2021) automates: train against the chip's own noise rather than a single nominal operating point, so the learned gate is not brittle.
Check yourself
Which statement about the two disciplined ways of handling uncertain data is right?
Use stochastic when you trust your probabilities and face the situation many times; use robust for a decision made once where one bad outcome is unacceptable.