What Is a Frozen Window in Scheduling?

A frozen window is a near-term time horizon inside which a reschedule cannot move jobs: any job that starts within the window is left exactly where it is when the plan is regenerated, while work outside the window is free to re-optimize. It is the mechanism that lets a planner refresh the schedule without disrupting jobs that are about to run or already running. The plain analogy is a school timetable: this week's classes are set, and changes only apply from next week.

This entry is part of the EDGEBIC glossary; see the manufacturing glossary for the wider vocabulary and the scheduling mode definition for how the freeze is applied in practice.

How a Frozen Window Works

A production schedule is regenerated often: a new order arrives, a machine goes down, priorities shift. Each regeneration is an opportunity to make the plan better, but also an opportunity to move work that people are already counting on. The frozen window resolves that tension by drawing a line in time.

When a reschedule runs with a frozen window, the engine identifies every job that starts inside the horizon and preserves it: same machine, same time, untouched. Everything that starts beyond the horizon is fair game for re-optimization. The result is a plan whose near term is stable and whose far term is fresh.

The window is measured from now. A short window (a few hours) protects only the immediately imminent work; a longer window (today and tomorrow, or the whole current week) protects more but leaves the engine less room to improve. The right size is a trade-off between stability and optimization, and it belongs to how your shop runs, not to any one job.

Jobs that are already in progress are always preserved, regardless of the window, because their work has started on the floor and cannot be un-started. The window is about protecting soon-to-start jobs; in-progress jobs are protected as a matter of course.

The window is a horizon, not a hard wall that jobs bounce off. A job that starts just inside it is held; a job that starts just outside it is free to move. That means the window's size directly shapes how much a reschedule can improve. A very short window leaves the engine almost total freedom but protects only the most imminent work; a window that covers the whole current week protects far more but leaves the engine less room to re-optimize the near term. There is no universally correct size, only the size that matches how far ahead your floor commits to a printed plan.

Why the Freeze Matters

The value of a frozen window is trust. A schedule is only useful if the people running it believe it, and belief is fragile near the present.

Consider a supervisor who prints the day's plan at 7 a.m. and assigns crews. If a reschedule at 10 a.m. reorders the 11 a.m. jobs (moving one from mill 2 to mill 3, swapping an operator's assignment), the printed plan is now fiction and the floor scrambles. After a week of that, supervisors stop looking at the live system and run from yesterday's paper. The frozen window prevents this by guaranteeing that a mid-day reschedule cannot touch the hours the floor is already executing. The plan stays honest, and the system stays trusted.

Planners call the opposite problem "nervousness": a schedule that twitches with every input. The frozen window is the direct antidote, trading a little optimization on the near term for a lot of stability where stability matters most.

A Concrete Example

A planner needs to add a rush order at 10 a.m. Today's jobs are already set up and running, and the supervisor's printed plan is on the floor.

Running a reschedule that preserves the near-term window, the engine holds every job starting inside the window exactly where it is: today's plan does not move. The rush order is placed in the earliest open capacity beyond the frozen horizon, tomorrow. No operator is reassigned mid-setup, no in-progress job is disturbed, and the printed plan the supervisor is working from stays correct. The planner got the new work into the schedule without paying for it in floor disruption.

A full reschedule from scratch would have done the opposite: cleared everything and replanned, potentially reordering today's work to fit the rush order in sooner. Choosing the near-term-preserving reschedule instead is what made the freeze hold.

How EDGEBIC Preserves the Frozen Window

In EDGEBIC by User Solutions, the frozen window is applied by the reschedule mode you choose. The production-safe refresh preserves jobs starting within the near-term window and all in-progress jobs, then reschedules everything else. A full reschedule deliberately does not freeze, because its purpose is to replan the whole plant after a major change. Matching the mode to your intent is how you control the freeze.

The distinction to keep straight is between a frozen window and a frozen routing. A frozen window protects when jobs run. A frozen routing protects what a specific in-flight job's steps are, locking a job to the routing that was in effect when it was scheduled so later edits do not rewrite it. For that companion concept, see why frozen routings protect in-flight jobs and how to work with frozen routings.

For the practical side of near-term stability across weekly runs, see keeping schedules stable week to week and the scheduling modes overview. The related engine concept of when work is placed forward or backward in time is covered in forward versus backward scheduling.

A frozen window is the promise that the plan will not pull the rug out from under the floor. It is what lets a planner improve next week's schedule without breaking this afternoon's.