Receding-Horizon Planning¶

Rolling-horizon planning method — instantiates Moving-Target Tracking

Plans over a look-ahead horizon but commits only the near term, then rolls the horizon forward and re-optimizes as the target and state move — trading plan permanence for continuous course-correction.

Against a moving target, a plan finished once is obsolete by the time it executes. Receding-Horizon Planning resolves that by treating the plan as deliberately provisional past its head: optimize a full look-ahead plan over some horizon, commit only its first block, execute that, then discard the rest and re-optimize from the realized state next step. The permanence you surrender on the tail is what buys the ability to track. Its distinguishing idea is the horizon mechanics — a firm committed head and a disposable, re-solved tail — as opposed to the calendar rhythm of when replanning happens (that is the planning cycle) or the control-loop mathematics of a plant model (that is model-predictive control). This is planning that is never finished on purpose.

Example¶

A parcel carrier plans deliveries across a full day, but the day never stops changing: new orders arrive, some cancel, traffic congeals. Receding-horizon planning fits this exactly. The next two-hour delivery wave is committed hard — drivers dispatched, routes locked — while the rest of the day, waves three through ten, is held as a provisional plan that will be re-solved before each wave launches. Only the imminent wave is real; everything behind it is the best current guess, expected to change.

Walk it forward: at each wave boundary the planner re-optimizes the remaining waves from the actual current state — trucks where they really are, orders as they now stand — commits the next wave, and rolls the horizon on. A fixed morning route sheet would be wrong by noon; this plan is never "done," yet its committed part is always current and its tail always reflects the latest target. The disposable tail isn't wasted work — it's the flexibility that keeps the committed head good.

How it works¶

Optimize over the horizon. Build a full plan out to a look-ahead horizon using the best current target and state.
Commit only the head. Lock a bounded near-term block and act on it; leave the tail explicitly provisional.
Roll and re-solve. Advance a step, re-optimize from the realized state, discard the old tail. The window recedes ahead of execution continuously.
Stay inside the envelope. Every re-solve is constrained to remain feasible, so the provisional tail never commits the plan to a path it cannot legally or physically take.

Tuning parameters¶

Horizon length — how far the look-ahead reaches. Longer gives foresight but spends effort optimizing a tail you will throw away; shorter is cheap but myopic and can paint the plan into a corner.
Commit-window size — how much of the head is locked before the next re-solve. Wider is stable but slow to react; narrower is responsive but risks churn.
Re-solve trigger — fixed step versus event-driven on material new information.
Recompute budget — how much replanning effort is spent per cycle, guarding against replanning that eats the capacity meant for execution.
Terminal constraint — how firmly the horizon's end is held to a feasible state, to stop the optimizer from grabbing near-term gains that strand it later.

When it helps, and when it misleads¶

Its strength is giving foresight without over-committing: when the target moves enough that a fixed plan goes stale, yet irreversible near-term actions must still be taken, the provisional tail carries genuine option value while the firm head keeps execution coherent. It is the method that lets you act now and still bend later.

Its failure modes cluster at the two dials. A horizon too short is myopic and corners the plan; too long wastes optimization on a tail that will be discarded. A commit window too rigid can't react; too loose churns. The classic misuse is perpetual replanning that never actually commits — re-optimizing so freely that nothing is ever locked and shipped — or its mirror, committing the head and then ignoring the re-solve. The discipline is to fix a real commit window and honor it, size the horizon to how fast the target moves, and budget replanning so it does not crowd out execution. The method descends from receding-horizon (model-predictive) control, where the same commit-first, re-solve-always logic is standard.^[1]

How it implements the components¶

Receding-Horizon Planning realizes the archetype's plan-structure machinery — the components that shape and constrain the rolling plan:

rolling_horizon_plan — its namesake output: the look-ahead plan with a firm head and a provisional, re-solved tail.
response_rule — the committed near-term block the plan emits each cycle is its response to the current tracking error.
feasibility_envelope — every re-solve is bounded to remain feasible, so no provisional tail commits to an infeasible path.

It does not set the calendar rhythm on which replanning recurs (update_cadence, multi_timescale_target_decomposition) — that is Rolling Planning Cycle; nor perform control-theoretic dead-time compensation — that is the sibling Model-Predictive Control / Smith Predictor; nor version the target it plans against — that is Objective Versioning and Change Log.

Instantiates: Moving-Target Tracking — this method is how the loop commits action under a moving target without freezing to a stale plan.
Consumes: State-Estimation Filter supplies the realized current state each re-solve starts from.
Sibling mechanisms: Rolling Planning Cycle · Model-Predictive Control · Smith Predictor or Model-Predictive Compensation · Rolling Forecast Review · State-Estimation Filter

Notes¶

The disposable tail is what people misread. It is not wasted planning — it is purchased flexibility, and treating it as a commitment (or skipping the re-solve to "save effort") collapses receding-horizon planning back into exactly the stale fixed plan it exists to avoid.

References¶

[1] Receding-horizon control — the core of model-predictive control — optimizes over a finite horizon, applies only the first control move, then re-optimizes from the new measured state. Planning at the organizational scale borrows the same commit-first, roll-forward structure; this mechanism is that idea lifted out of the control loop. ↩