Decision Latency Is a Cost | Learn

A lot of planning systems act as if a decision made Tuesday is economically equivalent to the same decision made Friday.

It usually is not.

By Friday, inventory has moved. Demand has happened. a supplier cutoff may have passed. A truck may already be booked. Production may have started. The forecast may have changed, but more importantly, the set of actions still available to you has changed.

That is decision latency. And it has a cost.

This is easy to miss because latency often lives outside the optimization model. The model receives a state, produces an answer, and reports an objective value. Nobody puts a line in the objective called three days spent waiting for approval.

The business still pays for it.

Start with the decision, not the dashboard

Suppose a replenishment system decides how much to order from an overseas supplier every week. Lead time is 16 weeks. Orders must satisfy case packs and a vendor-level MOQ. Demand is uncertain. Inventory is expensive, but stockouts are worse on high-margin items.

The obvious optimization question is:

How much should we order?

The better framing is:

At what time do we know enough to make the decision, when can we still act, what actions remain available at each point, and what happens economically if we wait?

Those questions expose the actual system.

Before writing a variable, ask:

What decision is being made?
Who or what can execute it?
What is the earliest time it can be made?
What is the last time it can be changed?
Which information arrives between those times?
Which options disappear while we wait?
What is truly committed versus merely planned?
If we miss the normal decision window, what recourse remains?

That last question matters. A late purchase order may still be possible, but only with air freight. A late production change may still be possible, but with a setup penalty. A late allocation decision may mean stealing inventory from another region.

Latency rarely makes the decision impossible all at once. It usually makes the next available decision more expensive.

Put time into the decision structure

For item (i), supplier (v), and period (t), a basic ordering model might contain:

[ x_{i,t} = \text{units ordered} ]

and perhaps:

[ y_{v,t} \in {0,1} = \text{whether a vendor order is opened} ]

with inventory balance, MOQ, pack-size, capacity, and budget constraints.

That is fine, but it says nothing about when the decision becomes executable.

A production system often needs additional structure around the optimization:

decision_time: when the recommendation was calculated,
approval_time: when it was accepted,
execution_time: when it reached the operational system,
commitment_time: when it became costly or impossible to reverse,
arrival_time: when the physical consequence occurs.

These timestamps are not audit trivia. They define the policy.

If an order recommendation is calculated Monday but consistently executed Thursday, your real policy is not the Monday policy. It is a Thursday policy using Monday’s state.

That distinction can be worth millions in a large network.

Stale state creates a different optimization problem

Let the true system state at time (t) be:

[ S_t = (I_t, P_t, F_t, C_t, K_t) ]

where:

(I_t) is on-hand inventory,
(P_t) is pipeline inventory,
(F_t) is the information available about future demand,
(C_t) is capacity and supplier availability,
(K_t) is the set of commitments already made.

A decision policy maps state to action:

[ X_t = \pi(S_t) ]

Now suppose the organization takes three days to approve the recommendation. The executed action is effectively:

[ X_{t+3} = \pi(S_t) ]

unless you rerun the policy before execution.

That is a very different thing from:

[ X_{t+3} = \pi(S_{t+3}) ]

The difference is not philosophical. Sales happened during those three days. Purchase orders may have arrived. Capacity may have been consumed by someone else. Another planner may have changed a constraint. A promotion may have been announced.

You are executing an action optimized for a state that no longer exists.

Measure the value of acting now versus later

A useful way to think about latency is through opportunity cost.

Let (V(S_t)) be the expected economic value of acting from state (S_t). If action is delayed by (\Delta), define latency cost approximately as:

[ L(\Delta) = V(S_t) - \mathbb{E}[V(S_{t+\Delta}) \mid \text{decision delayed}] ]

In practice, you usually do not have a closed-form value function. That is okay. Use simulation.

Take the same historical or synthetic starting state and compare policies:

Decide immediately.
Wait one day, update state, then decide.
Wait three days.
Wait one week.
Wait until the normal decision is no longer available and use the defined fallback.

Run all policies against the same demand, lead-time, capacity, and disruption samples. Then compare economic outcomes.

This gives you a latency curve rather than an argument in a meeting.

You may discover that the first 24 hours barely matter but day three is expensive because it crosses a supplier cutoff. Or that latency matters only for a small set of high-velocity items. Or that waiting actually has positive value in some cases because additional information arrives before commitment.

That last case is important: faster is not automatically better.

The goal is not zero latency. The goal is economically justified latency.

Waiting can have information value

Suppose you can order today or tomorrow. Tomorrow you receive an updated demand signal. If the supplier cutoff is Friday either way, waiting one day may be valuable.

The tradeoff is between information gained and optionality lost.

A simple decision comparison is:

[ \text{Value of waiting} = \text{information value} - \text{cost of lost options} ]

If waiting gives you a better estimate without changing the feasible action set, wait.

If waiting causes a vessel cutoff to be missed, removes regular freight, consumes scarce supplier capacity, or moves an order into a different production cycle, the cost may dominate.

This is why blanket rules such as “all orders require 72-hour approval” are dangerous. The economic effect of 72 hours depends on where the decision sits relative to operational breakpoints.

Decision latency creates hidden constraints

Organizations often describe approval processes as workflow. Operationally, they behave like constraints.

Imagine supplier capacity for period (t):

[ \sum_i x_{i,t} \le C_t ]

The optimizer solves with capacity (C_t = 10{,}000). During a two-day approval delay, another business unit consumes 4,000 units. The executable constraint is now:

[ \sum_i x_{i,t} \le 6{,}000 ]

The model was not wrong. The execution architecture invalidated its state.

The same thing happens with:

transportation slots,
production windows,
purchase budgets,
warehouse appointments,
promotional inventory,
labor capacity,
supplier MOQs that must be combined before cutoff,
inventory available for rebalancing.

If a resource can disappear between optimization and execution, model or simulate that timing explicitly.

Frozen windows are a latency response, not a law of nature

Many planning systems use frozen horizons: no changes inside two weeks, limited changes in weeks three and four, normal optimization afterward.

Sometimes this is exactly right. Physical commitments exist. Materials have been cut. Labor is scheduled. Containers are booked.

Sometimes the frozen window is just organizational scar tissue.

Ask what actually creates the freeze.

If changing a decision inside two weeks costs $4,000, model a change cost. If it is physically impossible, make it a hard constraint. If it is merely annoying, do not pretend it is impossible.

For a previously planned quantity (\bar{x}_{i,t}), introduce deviation variables:

[ d^+{i,t} \ge x{i,t} - \bar{x}_{i,t} ]

[ d^-{i,t} \ge \bar{x}{i,t} - x_{i,t} ]

and charge a realistic cost for changing the plan:

[ \min \quad \text{operating cost} + \sum_{i,t} c^{change}{i,t}(d^+{i,t}+d^-_{i,t}) ]

Now the model can decide whether the new information is worth disrupting the plan.

That is usually more honest than an arbitrary wall in time.

Recourse is what makes latency survivable

Real supply chains do not get one shot at the future. They act, observe, and act again.

A useful policy therefore includes fallback actions:

expedite an order,
transfer inventory between locations,
substitute products,
split shipments,
use alternate suppliers,
delay low-value demand,
change transportation mode,
override an MOQ at a penalty,
accept a stockout.

These are recourse decisions.

If your simulator assumes a perfect initial plan and no recourse, latency will look more damaging than it really is. If it assumes free, unlimited recourse, latency will look harmless.

Neither is useful.

Model the actions the business actually has, with the costs and limits they actually have.

Metrics that expose latency

Do not stop at solver runtime. Solver runtime is only one component of decision latency.

Track the full path from state to execution. Useful metrics include:

Metric	What it tells you
State-to-recommendation time	Data and optimization latency
Recommendation-to-approval time	Human or workflow latency
Approval-to-execution time	Systems integration latency
State age at execution	How stale the decision input really was
Percent executed unchanged	Whether recommendations survive the workflow
Value lost by delay	Economic consequence of latency
Recourse spend	Cost paid to recover from late decisions
Missed cutoff count	Operational breakpoints crossed
Decision churn	Whether faster replanning creates instability

I would also log the objective value of the recommendation when produced and reevaluate the same action against the state that existed when it was executed.

The gap is incredibly informative.

A practical simulation experiment

If you want to know whether decision latency matters in your system, do not start by redesigning the workflow. Run an experiment.

Take a representative set of historical decision dates. Reconstruct the information that was actually available at each date. For each state, simulate the same policy with different execution delays: zero hours, 24 hours, 72 hours, one week, and whatever delay your current process actually produces.

For every delay, preserve realistic behavior:

demand continues to occur,
inventory receipts arrive,
forecasts update only when they would have updated,
supplier capacity can change,
cutoffs can expire,
committed decisions remain committed,
recourse actions have real costs and limits.

Use common random numbers across delay policies so the comparison is not drowned in Monte Carlo noise.

Then measure expected profit, stockout cost, holding cost, expedite cost, write-offs, capacity violations, and decision stability.

You now have evidence about whether shaving two days from approval is worth anything.

Maybe it is worth $8 million annually. Maybe it is worth $80,000. Maybe the optimizer itself takes 90 seconds and everyone has been arguing about reducing it to 30 seconds while recommendations sit in an inbox for four days.

That happens more often than people want to admit.

Failure modes

Optimizing solver time while ignoring workflow time

A team celebrates cutting solve time from ten minutes to two. The plan then waits six hours for a batch job and two days for approval.

Profile the entire decision pipeline.

Using current state with an old recommendation

A UI shows today’s inventory beside a recommendation generated from yesterday’s inventory. The recommendation looks irrational because the state and action are from different timestamps.

Always display the state vintage used to generate the decision.

Treating all latency as equally expensive

One hour before a vessel cutoff can matter more than three days during a quiet part of the cycle.

Measure latency around operational breakpoints.

Assuming approval adds value because approval exists

Some reviews catch real problems. Others are ceremonial. Measure override rates, override quality, and economic outcomes.

A control that never changes the decision but delays every decision deserves scrutiny.

Automating a bad decision faster

Reducing latency does not rescue a poorly framed objective, bad state, missing constraint, or broken policy.

Speed multiplies whatever system you already built.

Ignoring decision churn

Near-zero latency can create a system that changes recommendations every time a tiny piece of information arrives. Operations may spend more reacting than executing.

Charge for instability where instability has a real cost.

What to do in practice

First, draw the decision timeline. Not the data architecture. Not the org chart. Draw when information arrives, when a decision can be made, when it can be changed, and when it becomes committed.

Second, identify the breakpoints where waiting changes the feasible action set or the economics. Supplier cutoffs, production freezes, freight bookings, budget locks, and capacity allocation windows belong on the timeline.

Third, instrument the production system. You need timestamps for state creation, recommendation, approval, execution, and commitment. Without those, you are guessing about latency.

Fourth, replay or simulate delay. Use the same uncertainty samples and compare economic outcomes under different delays.

Fifth, separate valuable waiting from useless waiting. If waiting produces information that improves the decision, keep it. If it is queue time, eliminate it. If it is a control, quantify what the control catches.

Finally, optimize the whole policy. That includes the mathematical model, the information process, the decision cadence, the approval mechanism, the execution system, and the available recourse.

A decision is not valuable when the solver finds it.

It is valuable when the business can still act on it.