A Simulator Is Not a Policy

A simulator can tell you what happens.

A policy tells you what to do.

That distinction sounds simple, but I see teams blur it constantly.

They build an impressive digital representation of a supply chain. Demand arrives. Inventory moves. Purchase orders are placed. Lead times vary. Capacity becomes constrained. Service levels rise and fall. Thousands of scenarios can be run in parallel.

Then someone asks the most important question:

“So what should we do?”

And the room gets quiet.

The simulator was never designed to answer that question.

This is one of the most common gaps in practical decision science. Organizations invest heavily in describing the world and assume that a sufficiently detailed description will eventually become a decision system.

It will not.

A simulator needs a decision rule inside it. Otherwise nothing acts.

The simulator needs something to simulate

Imagine a multi-echelon inventory system.

Demand occurs at stores. Stores replenish from distribution centers. Distribution centers replenish from suppliers. Lead times are uncertain. Supply is constrained. Orders have minimum quantities. Some products share transportation capacity. Some inventory can be rebalanced after demand is observed.

A simulation can represent all of this.

At each time step, it can update the state of the system:

• inventory on hand
• inventory in transit
• open purchase orders
• backorders
• forecast information
• supplier availability
• remaining capacity
• time until the next buying opportunity

But then the simulation reaches a decision point.

How much should we order?

The simulator does not know.

You have to give it a policy.

The policy might be simple:

Order enough to raise inventory position to a target.

It might be more sophisticated:

Compute a target from a probabilistic forecast, adjust for the economics of underage and overage, then allocate constrained supply across items according to marginal value.

It might call a MILP.

It might use approximate dynamic programming.

It might be a parameterized heuristic.

It might even be a learned policy.

But something has to map the current state into an action.

That mapping is the policy.

The simulator is the environment in which the policy lives.

Why the distinction matters

When teams confuse simulation and policy, they often make one of two mistakes.

The first mistake is building an extremely detailed simulator without a serious decision architecture.

The model can reproduce historical inventory, lead times, stockouts, and flows with impressive fidelity. But when it is time to improve decisions, the only available policy is the same business rule already used in production.

The team has built a better microscope.

They have not built a better decision maker.

The second mistake is treating the simulator itself as if it should choose actions.

This usually happens when someone says:

“Why don’t we just simulate every possible decision and pick the best one?”

Sometimes that works.

If there are five candidate order quantities and the decision is made once, simulate all five.

But real supply chains are sequential.

Today’s order changes tomorrow’s state. Tomorrow’s state changes the next decision. Future demand changes what inventory remains. Future decisions respond to that new information.

The number of possible action sequences grows quickly.

You are no longer asking the simulator to evaluate five choices.

You are asking it to search over a decision process.

That is an optimization problem.

Simulation can evaluate a policy

Suppose we have a replenishment policy with three tunable parameters:

• a service-risk parameter
• a buying-cadence parameter
• a capacity-reservation parameter

For any fixed parameter setting, the policy can make decisions throughout a simulated year.

We can then measure:

• profit
• service level
• average inventory
• emergency shipments
• order frequency
• capacity violations
• downside risk

Now simulation becomes extremely powerful.

We can compare policies under the same demand and supply scenarios.

We can ask whether a policy that looks good on average fails badly during disruptions.

We can test whether reducing order frequency saves transportation cost but creates unacceptable inventory risk.

We can examine the full distribution of outcomes rather than a single expected value.

This is policy evaluation.

The simulator tells us what happens when a policy interacts with uncertainty over time.

That is different from the policy itself.

Simulation optimization closes the loop

Now suppose we want to tune those three policy parameters automatically.

We choose a candidate parameter setting.

We run the policy through many simulated futures.

We measure the outcomes.

Then a search procedure proposes a better candidate.

Repeat.

The outer loop might use Bayesian optimization, local search, evolutionary search, random search, or another derivative-free method.

The inner loop is the simulator.

The object being tuned is the policy.

This architecture is useful because many real decision systems are too messy for a single clean mathematical formulation.

The simulator may contain:

• nonlinear business logic
• discrete events
• uncertain lead times
• black-box operational rules
• complex interactions across time

The policy may contain:

• forecasts
• critical-ratio logic
• target inventory positions
• balancing rules
• a MILP for constrained allocation
• practical guardrails

Trying to collapse all of that into one giant optimization model may be unnecessary or intractable.

Instead, we can optimize the policy by evaluating how it behaves inside the simulator.

But simulation optimization does not eliminate policy design

This is where another mistake appears.

People sometimes assume that once simulation optimization is available, they no longer need to think carefully about the policy.

Just give the optimizer enough knobs and let it search.

That is usually a bad idea.

A search algorithm can tune the policy class you give it.

It cannot rescue a policy class that does not contain useful behavior.

If your replenishment policy can only choose one fixed safety-stock multiplier for every item, no amount of simulation will discover item-specific economics.

If your allocation policy cannot reserve inventory for future high-value demand, the optimizer cannot invent that action.

If your buying policy ignores order calendars, the search procedure will tune the wrong system.

The design of the policy still matters.

Good simulation optimization starts with a policy architecture that reflects the real decision.

Then search tunes the parts that are difficult to derive analytically.

The best systems often combine methods

There is a tendency to ask whether a problem should use MILP, simulation, reinforcement learning, heuristics, or probabilistic forecasting.

In practice, the strongest systems often use several.

A probabilistic forecast describes uncertain demand.

A policy converts the current state and forecast into a decision problem.

A MILP resolves a constrained allocation decision.

A simulator evaluates the resulting policy across time.

An outer optimization loop tunes parameters that are difficult to set directly.

Replay testing checks whether the whole system would have behaved sensibly in historical operating conditions.

Monitoring measures whether production behavior is drifting away from what was tested.

These methods are not competitors.

They solve different parts of the decision architecture.

Aggregation can hide the decision you actually have

This distinction becomes especially important when uncertainty is aggregated over time.

Suppose a buyer is deciding how much inventory to protect over the next eight weeks.

For one problem, it may be enough to model total demand over the full eight-week window.

A scenario might say:

Total demand over the ordering window is 1,000 units.

That can be appropriate when the decision is primarily about how much inventory is needed over the full exposure period.

But now consider a different question:

What happens to inventory each week, and when do we stock out?

The same total demand can produce very different outcomes.

Demand of 125 units every week is not operationally equivalent to 700 units arriving in week one and 300 units arriving later.

If timing affects inventory state, replenishment opportunities, capacity, or future actions, the simulator needs a path.

The right representation of uncertainty depends on the decision being evaluated.

This is a general principle:

Do not choose the uncertainty model first.

Choose the decision first.

Then represent uncertainty at the resolution required to evaluate that decision.

A practical architecture

For many supply chain problems, I like to think in five layers.

1. State

What do we know now?

Inventory, pipeline, forecasts, capacity, prices, open orders, calendars, and anything else available at decision time.

2. Uncertainty

What may happen next?

Demand, lead times, supply availability, cancellations, returns, disruptions, and other unknowns.

3. Policy

Given the current state, what action do we take?

Order, allocate, expedite, rebalance, reserve, produce, or wait.

4. Transition

After the action and new information, how does the system change?

This is where the simulator is often most valuable.

5. Evaluation

How do we judge the policy?

Profit, service, inventory, risk, stability, workload, or some multi-objective combination.

When these layers are explicit, technical conversations become much clearer.

You can ask whether the forecast is wrong, the policy is wrong, the simulator is wrong, or the objective is wrong.

Without this separation, everything becomes “the model.”

And when “the model” fails, nobody knows what to fix.

The management problem is the same as the technical problem

This architecture also clarifies ownership.

Who owns the forecast?

Who owns the decision policy?

Who owns the business objective?

Who decides which guardrails are mandatory?

Who approves changes to policy parameters?

Who investigates overrides?

Who is accountable when the system behaves exactly as designed but the business dislikes the result?

These are not governance questions added after the technical work.

They are part of the decision system.

A simulator can expose tradeoffs, but it cannot decide what the organization values.

An optimizer can find the best action for an objective, but it cannot decide whether that objective reflects the business.

A policy can automate decisions, but someone still owns the policy.

An Optimization University rule

When someone shows you a simulation, ask:

What policy is acting inside it?

When someone shows you an optimization model, ask:

What happens after this decision is implemented and new information arrives?

When someone shows you a forecast, ask:

Which decision changes because of this distribution?

These three questions expose a surprising amount of confusion.

The goal is not to build the most sophisticated simulator.

The goal is not to build the most sophisticated optimizer.

The goal is to build a system that repeatedly makes better decisions as information arrives.

That requires an environment, a policy, and a way to learn whether the policy is actually good.

A simulator is not a policy.

But paired with a well-designed policy, it can become one of the most powerful tools we have for building decision systems that survive contact with reality.