A Demand Distribution Is Not a Demand Path

A probabilistic forecast is not automatically a good uncertainty model.

That statement will annoy some people because probabilistic forecasting is usually presented as the sophisticated alternative to point forecasting. Instead of saying demand will be 1,000 units, we produce a distribution. Maybe the 10th percentile is 800, the median is 1,000, and the 90th percentile is 1,300.

Better? Usually.

Enough? That depends entirely on the decision.

Suppose I need to place one order today that must cover the next eight weeks. If the only decision is how many units to buy now, the distribution of total demand over those eight weeks may be exactly what I need.

Now suppose I want to simulate inventory, evaluate service, model replenishment, or decide whether a policy survives a promotion in week three and a supplier delay in week five. The same distribution is no longer enough.

I need a demand path.

Those are different objects. Practitioners get into trouble when they build one and quietly use it as if it were the other.

Start with the decision, not the forecast format

Before deciding how to represent uncertainty, ask what the system actually controls.

Is the decision:

• one order quantity placed today?
• a weekly sequence of replenishment decisions?
• a capacity reservation made before demand arrives?
• an allocation decision that can be revised every day?
• a safety-stock parameter that will govern thousands of future decisions?
• a policy that reacts to inventory, pipeline, forecast updates, and time?

The uncertainty model should be built for that decision.

This sounds obvious. It is not how many systems are built.

A forecasting team produces weekly quantiles because weekly quantiles are what the forecasting platform produces. An optimization team samples those quantiles because they are available. A simulation team then treats the samples as demand trajectories. Everyone is doing something mathematically defensible in isolation, but the full system may still represent the wrong problem.

The first question is not, “Do we have a probabilistic forecast?”

The first question is, “What uncertainty must this decision survive?”

Total demand and demand timing answer different questions

Consider an eight-week horizon.

Two possible futures are:

Week	Path A	Path B
1	300	50
2	250	75
3	150	100
4	100	125
5	75	150
6	50	175
7	40	225
8	35	300
Total	1,000	1,200

The totals differ, so a distribution of total demand can distinguish these two outcomes.

But now consider two different paths with the same total:

Week	Path C	Path D
1	400	25
2	250	50
3	150	75
4	75	100
5	50	125
6	25	150
7	25	200
8	25	275
Total	1,000	1,000

For a one-time order with no replenishment and no meaningful timing cost, those futures may lead to the same decision. Buy enough to cover the economically appropriate quantile of total demand.

For an inventory simulation, they are not remotely the same.

Path C may stock out in week two while Path D carries excess inventory for most of the horizon. The total demand is identical. The inventory trajectory is not.

This is the core distinction:

A distribution of total demand describes how much may happen. A demand path describes how uncertainty unfolds through time.

If timing changes the economics, timing belongs in the uncertainty model.

When an aggregate distribution is enough

There are many decisions where aggregation is not a shortcut. It is the right abstraction.

Suppose we place one irreversible order at time zero:

[ q \ge 0 ]

Demand over the relevant protection period is the random variable:

[ D_H = \sum_{t=1}^{H} D_t ]

A simple economic objective might be:

[ \min_q ; c_o,\mathbb{E}[(q-D_H)^+] + c_u,\mathbb{E}[(D_H-q)^+] ]

where:

• (c_o) is the cost of excess,
• (c_u) is the cost of shortage,
• (D_H) is total uncertain demand over the decision’s protection horizon.

If nothing important happens between now and the end of the horizon, modeling every week separately may add complexity without changing the decision.

The aggregate distribution can be appropriate when:

• there is one decision before uncertainty is revealed,
• the decision cannot be revised during the horizon,
• timing inside the horizon does not materially affect cost or feasibility,
• lead time and service are represented at the same aggregate level,
• no intermediate capacity or inventory constraint can bind.

In that case, sampling total demand directly can be efficient and statistically clean.

The mistake is not aggregation.

The mistake is forgetting what information aggregation destroyed.

When you need a path

You need a path when the sequence of events changes the outcome.

That usually happens when the system has state.

Inventory is state. Backlog is state. Pipeline inventory is state. Capacity consumed this week changes capacity available next week. Cash spent now may not be available later. Shelf life decreases with time. A stockout today can lose demand that cannot be recovered tomorrow.

A basic inventory transition is:

[ I_{t+1} = I_t + A_t - D_t ]

where:

• (I_t) is inventory at the start of period (t),
• (A_t) is arriving supply,
• (D_t) is realized demand.

Once the model contains a transition like this, the path matters.

The same total demand can produce different:

• stockout timing,
• lost sales,
• backlog duration,
• holding cost,
• emergency freight,
• order triggers,
• capacity violations,
• expiration,
• customer service.

A simulator that receives only total eight-week demand has no honest way to reconstruct those outcomes unless it makes additional assumptions about how demand is distributed across time.

At that point, the simulator is not merely consuming the forecast. It is inventing part of the future.

That may be necessary. It should not be invisible.

Marginals are not a joint distribution

There is another trap.

Suppose the forecasting system gives a probabilistic forecast for each week. We now have eight weekly distributions.

Do we have a demand-path model?

Not yet.

A path requires a joint distribution across time.

Weekly marginals tell us the uncertainty in each period. They do not tell us how periods move together.

If week one is unexpectedly high, does that make week two more likely to be high?

Maybe demand has persistent level error, so yes.

Or maybe customers pulled purchases forward, so a high week one makes week two lower.

Or maybe a promotion creates a temporary spike with no information about later demand.

If we independently sample each weekly marginal, we assume away these relationships.

That can create unrealistic paths: one week at the 95th percentile, the next at the 5th, then the 90th, then the 10th, even when real demand errors are strongly persistent.

The model may have perfectly calibrated weekly quantiles and still generate terrible trajectories.

This is why path generation is not just repeated random sampling.

Questions to ask before generating scenarios

Before writing simulation code, I would ask:

1. What decision is being evaluated? One order, repeated orders, allocation, capacity, or a policy parameter?
2. When can the decision change? Never, weekly, daily, or when an event occurs?
3. What state carries forward? Inventory, backlog, pipeline, cash, capacity, age, commitments?
4. Which sequence effects matter economically? Early stockouts, late arrivals, persistent demand error, promotions, seasonality?
5. What information will the real policy observe? Actual demand, revised forecasts, supplier updates, inventory corrections?
6. Which dependencies must scenarios preserve? Across time, products, locations, suppliers, or all four?
7. What metric could be wrong even if total demand is right? Service level is the usual answer.

These questions determine the uncertainty representation.

Not the forecasting library.

A practical policy structure

Suppose the real system orders every week. A simple policy might be:

[ q_t = \max\left(0, T_t - IP_t\right) ]

where:

• (q_t) is the order placed at time (t),
• (T_t) is a target inventory position,
• (IP_t) is current inventory position.

The target might depend on information available at the time:

[ T_t = \pi(S_t, F_t, \theta) ]

where:

• (S_t) is operational state,
• (F_t) is the current forecast information,
• (\theta) contains tunable policy parameters.

Now the system is sequential.

To evaluate it, we need to simulate:

1. the current state,
2. the policy decision,
3. uncertain demand and supply,
4. the state transition,
5. the next decision with updated information.

A single draw of total horizon demand cannot evaluate that loop.

The policy may react well to gradual demand growth and badly to a sudden spike. It may recover from a supplier delay if it sees the delay early. It may overreact to noisy forecast revisions. Those behaviors exist only in paths.

The same uncertainty model should not serve every layer

A mature decision system may use several uncertainty representations at once.

That is not inconsistency. It is good design.

For example:

• Buying decision: distribution of total demand over the ordering window.
• Inventory simulation: weekly demand and lead-time paths.
• Network stress test: correlated regional demand scenarios.
• Capacity reservation: distribution of peak load, not average volume.
• Executive reporting: a small set of interpretable economic outcomes.

Trying to force one universal scenario set into every decision often makes the system harder to understand and less accurate where it matters.

The right question is not, “What is our official forecast?”

It is, “What random object does this decision need?”

Constraints change the required resolution

Uncertainty resolution should match constraint resolution.

If warehouse capacity is enforced weekly, monthly demand scenarios may hide violations.

If supplier capacity is daily, weekly averages may produce plans that look feasible but cannot execute.

If a minimum order quantity applies only when an order is placed, the timing of replenishment decisions matters.

A sequential optimization model might include:

[ q_t \le M y_t ]

[ q_t \ge MOQ \cdot y_t ]

with binary variable (y_t) indicating whether an order is placed.

Now the timing of demand can change not only inventory outcomes but the number and size of orders. Two paths with identical total demand can trigger different fixed costs, MOQs, and capacity constraints.

Aggregation can erase the exact mechanism that makes the optimization problem interesting.

Do not confuse more detail with more realism

There is an opposite failure mode: adding enormous scenario detail because it feels sophisticated.

A model with 10,000 weekly paths is not automatically more realistic than a model with 500 aggregate samples.

More dimensions create more ways to be wrong.

You can generate beautifully detailed nonsense.

Path models require choices about:

• temporal correlation,
• cross-item correlation,
• cross-location correlation,
• forecast revision behavior,
• promotion effects,
• stockout censoring,
• new-product uncertainty,
• lead-time dependence.

If none of these assumptions have been validated, the model may simply move uncertainty from an explicit simplification into hidden code.

Use the least complicated uncertainty representation that preserves the economics of the decision.

That is the standard.

Implementation notes that matter

Preserve the forecast vintage

A simulation should not give the policy future information.

If the policy makes a decision on January 1, use the forecast that was available on January 1. Do not use a forecast rebuilt later with corrected history and future observations.

This leakage is common and can make weak policies look excellent.

Separate the world from the policy

The simulator should generate or replay what happens. The policy should decide what to do.

Do not let scenario-generation code quietly contain ordering logic. Do not let the policy peek at future scenario values.

Keep the interface explicit:

[ \text{state} \rightarrow \text{decision} \rightarrow \text{uncertainty} \rightarrow \text{next state} ]

Use common random numbers for policy comparisons

If you compare Policy A and Policy B, evaluate them on the same demand and supply paths.

Otherwise, the difference in performance may be scenario noise rather than policy quality.

Validate paths, not just marginals

Check more than weekly calibration.

Compare simulated and historical:

• run lengths above and below forecast,
• autocorrelation of forecast errors,
• cumulative demand over multiple horizons,
• peak demand,
• cross-item and cross-location dependence,
• stockout timing,
• forecast revision patterns.

A path generator should reproduce the features that drive the decision.

It does not need to reproduce everything.

Metrics should match the decision too

Forecast metrics alone are not enough.

For an aggregate buying decision, useful metrics may include:

• expected shortage cost,
• expected excess cost,
• profit,
• return on inventory investment,
• downside risk.

For a sequential inventory policy, add:

• fill rate,
• stockout frequency,
• stockout duration,
• backlog age,
• average and peak inventory,
• expedite frequency,
• order frequency,
• policy stability.

I would also inspect the distribution of outcomes, not only the mean.

A policy with slightly better average profit but catastrophic tail behavior may be unacceptable. A policy with a higher fill rate may achieve it by carrying absurd inventory. A lower forecast error may not improve either decision.

The metric should expose the economic tradeoff.

Common failure modes

Sampling weekly quantiles independently

This often creates unrealistic zigzag paths and destroys persistence.

Taking total demand and spreading it evenly across time

This preserves the total while manufacturing smoothness. It usually understates stockout and capacity risk.

Using one scenario model for every decision

Different decisions lose different information when uncertainty is aggregated.

Evaluating a sequential policy with static scenarios

If the real policy reacts to new information, the evaluation must reproduce the information flow.

Adding path detail without validating dependence

More granular random numbers are not the same as a better model.

Measuring the forecast instead of the decision

A well-calibrated scenario generator can still support a bad policy. A modest forecast can support a strong decision if the economics are modeled correctly.

What I would do in practice

I would start with the decision timeline on a whiteboard.

Mark when decisions are made. Mark when uncertainty arrives. Mark what the system knows at each decision. Mark what state carries forward.

Then choose the random object.

If the decision is one irreversible buy over a protection period, start with the distribution of total demand over that period.

If the decision repeats and state evolves, build paths.

If multiple products or locations compete for shared capacity, preserve the dependencies that create simultaneous stress.

Then test the uncertainty model against the decision metrics it is supposed to support.

Do not ask whether the scenarios look statistically impressive.

Ask whether changing the uncertainty representation changes the decision for reasons that make operational sense.

That is the real test.

A probabilistic forecast is an input. A scenario is a representation of a possible world. A simulator evaluates what happens in that world. A policy decides what to do as the world unfolds.

Those are four different things.

The systems that work in practice usually keep them separate.