How a Scheduler Recovers From a Mid-Shift Disruption

A scheduler recovers from a mid-shift disruption by re-planning only the remaining work, forward from where the shop floor actually is, while every completed operation stays frozen in place. A reschedule is surgical, not a full reset. It distinguishes three zones: completed work that is permanent history, in-progress work whose remaining balance shifts, and not-yet-started work that re-plans from scratch. EDGEBIC by User Solutions builds this on one non-negotiable rule, that an operation with logged actuals is never re-placed, which is what keeps a schedule honest when a machine breaks or an operator goes home early.

The three zones of a reschedule

When you press reschedule after a disruption, the engine classifies every operation of the affected job into one of three zones.

The resume point becomes the latest actual timestamp on the job, and the remaining steps cascade forward from there. Most scheduling systems treat a reschedule as wipe-and-rerun, which loses shop-floor reality. The three-zone model keeps the past intact and only optimizes the future.

Why completed work never moves

An operation with a logged actual end is a fact. The hours were worked, the labor was paid, the reports depend on it. Rewriting its dates on a reschedule would corrupt the audit trail and confuse the floor. So the engine preserves that row exactly as recorded and re-plans around it. This claim is documented and firm: completed work is never moved by a reschedule.

The rule extends to the messy middle. An operator who logs a start but no end has an in-progress operation. The engine locks its work center and schedules only the remaining balance forward. It never backfills a projected end that would freeze the row as complete, because the operator's real end still has to be honored later.

A worked recovery: machine down, two steps done

A four-step job. Steps 1 and 2 finished this morning; steps 3 and 4 had not started when the machine went down for two days.

Step 1 Cut:    actual Mon 08:30 to Mon 15:15   COMPLETED  -> preserved
Step 2 Drill:  actual Mon 15:15 to Tue 11:00   COMPLETED  -> preserved
Step 3 Paint:  no actuals                       REMAINING  -> rescheduled
Step 4 QC:     no actuals                       REMAINING  -> rescheduled

The reschedule sets the resume point to step 2's actual end, Tuesday 11:00, keeps steps 1 and 2 exactly as they happened, and slides steps 3 and 4 to the next available capacity after the machine returns. The finished work is untouched; only the remaining steps move. The machine breakdown walkthrough shows a full outage with the date arithmetic.

A worked recovery: the short confirm

Disruptions are not only breakdowns. An operator who closes a job early is one too. Take a 16-hour operation where the operator marks it complete Wednesday morning but only logged 10 hours over two days.

The engine detects the gap, 16 planned minus 10 actual, and forward-shifts it rather than trusting the early close blindly:

Historical block: 10 h preserved, operator's completion stamp kept
Remaining 6 h:    scheduled forward from the resume point
Downstream steps: queue after the 6-hour gap finishes

You get two rows for the step, the historical portion and the forward-shifted gap. No hours are invented and none are discarded. The site policy governs whether a short confirm forward-shifts, is trusted as-is, or is flagged per step, so a shop can choose how much to trust an early close.

The stale-reservation guard

There is one subtlety that makes reschedules behave. Before re-planning, the engine releases the old reservations of any job it is rescheduling, keeping only the rows that carry actuals. If it did not, the job's own out-of-date plan would still look booked, and the new allocation for a remaining step could get pushed days into the future because the machine appears full of the job's own stale reservations. Releasing them first is what lets the remaining steps slot into the real gap the disruption opened.

Jobs not in the reschedule keep every reservation, so re-planning one job never disturbs another's committed capacity. That targeting is why you can reschedule a single order after an operator logs actuals and leave the rest of the plant untouched.

Direction after a disruption is always forward

A job that has started always re-plans forward from its resume point, even if it was originally a backward or just-in-time job. Once execution has begun, "start as late as possible" is meaningless, so actuals override a backward request. This is a fixed rule in the direction precedence, covered alongside the other cases in push vs pull scheduling.

The payoff: a plan the floor trusts

The reschedule reads the way a supervisor expects: the past is frozen, the future is honest. That trust is the whole point. A schedule that rewrites finished work on every reschedule gets ignored; a schedule that preserves reality gets used. How much the future is allowed to churn is a separate lever, covered in why schedule stability can beat schedule optimality. The full six-phase reschedule pipeline lives in the scheduling engine guide. Log an actual and reschedule your own job to see the three zones in EDGEBIC.