Recourse Is Part of the Policy

A supply chain plan is usually presented as a table of numbers.

Order 4,000 units this week. Produce 1,200 cases next Tuesday. Move 600 units from the DC to the West region. Use ocean freight. Hold enough inventory to cover the promotion.

That table looks like the decision.

It is not the whole decision.

The missing part is what you will do when reality disagrees with the assumptions behind the table.

Demand comes in 30% above forecast. A supplier slips two weeks. A truck lane closes. A promotion gets moved. Inventory that the system thought existed turns out to be damaged. A vendor accepts only part of the purchase order. A factory loses a shift.

If your planning system has no explicit answer to those events, then the real policy is whatever a planner improvises afterward.

That improvisation is recourse. It should be modeled as deliberately as the original order quantity.

Start With the Decision Timeline

Before choosing an optimization method, write down the sequence of decisions and information.

Suppose a retailer buys an imported product with an eight-week nominal lead time. Today it can place a purchase order. Three weeks from now it may receive a better demand signal. Four weeks from now it may be able to expedite some quantity by air. Six weeks from now it can rebalance inventory across regions. Once the product reaches the country, it can allocate units among fulfillment centers.

Those are not implementation details. They define the decision problem.

A useful framing is:

1. What must be decided now?
2. What uncertainty is unresolved when that decision is made?
3. What new information will arrive later?
4. Which decisions can still be changed after that information arrives?
5. What does changing them cost?

The first decision may be a purchase quantity. The later decisions may include expediting, canceling, reallocating, substituting, transferring, or accepting a stockout.

A model that optimizes only the first decision while pretending the later actions do not exist can easily recommend the wrong first decision.

A Simple Example

Assume you must choose an initial order quantity x before demand is known.

Later, after demand scenario s is observed, you may expedite e_s units at a premium.

A simple two-stage formulation is:

minimize
    purchase_cost * x
  + E_s[
        expedite_cost * e_s
      + holding_cost * leftover_s
      + lost_sale_cost * shortage_s
    ]

subject to something like:

available_s = initial_inventory + x + e_s

leftover_s >= available_s - demand_s
shortage_s >= demand_s - available_s

x >= 0
e_s >= 0

The important distinction is not the algebra. It is the timing.

x must be the same across all scenarios because you choose it before learning which scenario occurs.

e_s can differ by scenario because it is a recourse decision made after information arrives.

That single modeling distinction changes the economics of the first order.

If expediting is impossible, you may need to buy more upfront. If expediting is cheap and reliable, buying less upfront may be rational. If expediting has limited capacity, the answer may sit somewhere in between.

The value of flexibility belongs in the first decision.

Static Plans Usually Hide Recourse Anyway

Many production planning systems are technically deterministic but operationally stochastic.

The optimizer produces a deterministic plan. Then humans repair it.

A planner expedites an order. A buyer negotiates around an MOQ. Operations moves inventory between buildings. Finance approves an exception. A merchant substitutes one item for another. Someone manually changes the forecast because the planning system has no better place to encode new information.

The organization therefore already has a recourse policy. It is just undocumented, inconsistent, and often invisible to the analytical system.

This is why planner overrides are so valuable. They reveal the actions the formal model forgot existed.

Before building a sophisticated stochastic program, inspect the exceptions people make today.

Ask:

• What gets expedited?
• What gets canceled?
• When do planners transfer inventory?
• Which shortages are tolerated?
• Which customer or channel gets protected first?
• When does someone violate the nominal planning rule?
• What information triggered the exception?
• What did the exception cost?

Those answers often tell you what the second-stage decisions should be.

Recourse Changes the Meaning of Risk

Consider two products with identical demand distributions.

Product A can be replenished domestically in two days at a moderate premium.

Product B comes from a specialized overseas supplier with a four-month lead time and no substitute.

If you model only demand uncertainty, the products may look similar.

Operationally, they are completely different.

Product A has cheap recourse. Product B has almost none.

The cost of being wrong is therefore not determined by forecast error alone. It depends on the actions available after the error becomes visible.

This is one reason generic safety-stock formulas can be misleading. They compress uncertainty into a buffer while often ignoring the flexibility of the decision process.

A business with fast replenishment, substitution, transfers, or flexible capacity may rationally carry less inventory than a business facing the same demand uncertainty without those options.

The Decision Variables Should Match Real Actions

A practical model might include first-stage decisions such as:

• purchase quantity by vendor and item,
• production reservation,
• transportation mode reservation,
• initial allocation,
• committed capacity.

Then recourse decisions by scenario or simulated future might include:

• emergency replenishment,
• air freight,
• cancellation,
• regional transfer,
• substitution,
• overtime,
• backordering,
• markdown,
• disposal,
• lost sales.

Do not add variables merely because a solver can handle them. Add actions that the business can actually execute.

A mathematically attractive recourse action that operations cannot perform is fake flexibility. It will make the first-stage decision look safer than it really is.

Constraints Matter More After Uncertainty Appears

Recourse is rarely unlimited.

Emergency freight has capacity. Transfers take time. Suppliers have minimum order quantities. Overtime has labor limits. Cancellation may only be allowed before a production cutoff. Substitution may be acceptable for one customer but prohibited for another.

These restrictions should appear explicitly.

For example:

e_s <= emergency_capacity_s

or:

transfer_{i,j,s} <= available_inventory_{i,s}

or a cutoff rule that prevents cancellation after a certain state transition.

The interesting part of the model is often the boundary between what is still reversible and what has become committed.

That boundary can matter more than the nominal planning horizon.

Do Not Give the Model Information From the Future

Recourse models introduce an easy way to cheat accidentally.

Suppose you simulate 100 future demand paths. If the optimizer is allowed to choose today’s order separately for each path, it has perfect foresight.

The results will look incredible.

They are also useless.

Decisions made before uncertainty is revealed must satisfy non-anticipativity: two futures that are indistinguishable at the time of a decision must receive the same decision.

This sounds academic, but the practical test is simple:

At the moment this action is chosen, would the planner actually know which future they are in?

If the answer is no, the model cannot condition that action on future information.

The same rule applies in simulation. A policy can react to observed state, not to the random numbers the simulator has already generated internally for future weeks.

Full Stochastic Programming Is Not Always Necessary

Once people hear “recourse,” they often jump directly to scenario trees and giant stochastic MILPs.

Sometimes that is appropriate. Often it is not.

There are several practical architectures.

Two-stage stochastic optimization

Use a common first-stage decision and scenario-specific recourse decisions. This works well when the decision timeline has a meaningful commit-now / react-later structure and the scenario count is manageable.

Rolling-horizon optimization

Optimize using current information, execute only the near-term decision, observe new state, and solve again. This is often the natural production architecture when decisions are revisited frequently.

Parameterized policy plus simulation

Define a policy such as:

if projected shortage > threshold:
    expedite up to capacity

or:

order = max(0, target_position - inventory_position)

Then tune the policy parameters through simulation.

This can be far easier to operate than a large multistage stochastic model while still capturing the essential economics of recourse.

Hybrid optimization and policy logic

Use a MILP for the coupled decision that benefits from global optimization, then embed explicit operational recourse rules in simulation or downstream execution.

The right architecture depends on the decision, not on which algorithm sounds most sophisticated.

Simulation Is Where Recourse Becomes Real

A deterministic backtest cannot tell you much about a recourse policy.

You need to simulate the sequence:

state
  -> decision
  -> uncertainty realizes
  -> state changes
  -> new information arrives
  -> recourse decision
  -> next state

For supply chain systems, the state might include:

• on-hand inventory,
• open purchase orders,
• age of inventory,
• supplier status,
• forecast vintage,
• capacity remaining,
• cash committed,
• orders already past cancellation cutoff.

The simulator should expose only information that would be available at each decision point.

Then evaluate the complete policy, not just the initial optimization output.

Measure Economics, Not Heroics

A bad recourse system can appear successful because planners save it constantly.

If every shortage is fixed with air freight, fill rate may look excellent while profit quietly disappears.

Track the cost of recovery explicitly.

Useful metrics include:

• expected contribution profit,
• lost-sales cost,
• expedite spend,
• transfer cost,
• cancellation penalties,
• overtime cost,
• inventory holding and obsolescence,
• frequency of emergency actions,
• tail loss under bad scenarios,
• decision stability,
• percentage of volume requiring manual intervention.

A good policy does not merely survive uncertainty. It makes economically sensible use of flexibility.

Common Failure Modes

Pretending recourse is free

If the model can always expedite without a premium or capacity limit, it will under-order initially and rely on fictional flexibility.

Pretending recourse does not exist

The opposite error produces excessive buffers because the model assumes every initial mistake is permanent.

Modeling actions that operations cannot execute

A solver recommendation is irrelevant if the supplier contract, transportation network, or warehouse process cannot support the action.

Giving the model perfect information

Scenario-specific early decisions create optimistic results through look-ahead leakage.

Ignoring recourse lead time

An expedite decision made after the stockout has already happened is not recourse. It is a postmortem.

Optimizing service while ignoring recovery cost

A policy can achieve spectacular service by spending absurd amounts on emergency actions.

Building a huge scenario tree before understanding the workflow

The decision timeline should come first. Scenario machinery comes later.

What to Do in Practice

Start with one recurring operational decision.

Draw the timeline from today until the consequence of that decision is mostly resolved. Mark when information arrives and when actions become irreversible.

Then write three columns:

Before uncertainty	New information	Available recourse
Place supplier PO	Demand update	Expedite
Reserve production	Yield observed	Add overtime
Allocate inbound stock	Regional sales observed	Transfer inventory
Book ocean freight	Promotion confirmed	Switch some volume to air

Put actual costs and capacity limits on the recourse actions.

Next, build the smallest model or policy that respects that sequence. Do not start with a giant multistage formulation.

Replay it against historical states where possible, then simulate plausible futures. Compare it with the current operating policy using economic metrics.

Finally, inspect when the proposed policy uses recourse. If the model expedites constantly, something is wrong: the initial decision may be too aggressive, expedite cost may be understated, or the assumed emergency capacity may be unrealistic. If it never uses recourse, either the option has no value or the model has made it artificially expensive.

The pattern of recourse is itself a diagnostic.

The Bigger Point

Optimization under uncertainty is not primarily about generating more scenarios.

It is about representing the sequence of decisions correctly.

What do I decide now? What will I learn later? What can I still change when I learn it? What will that flexibility cost?

A plan that answers only the first question is incomplete.

The real object being designed is a policy: a rule for taking actions as information arrives and the state evolves.

Recourse is not what happens after the optimization fails.

Recourse is part of the optimization problem.