How the Optimizer Preserves Completed and Started Work

The optimizer never moves work that is already done: completed operations pass through both the optimize step and Accept byte-identical, using the same actuals-preservation machinery as any reschedule. Work that has happened on the floor keeps its recorded actual dates and hours, no matter which goal you run or which engine you pick. The optimizer only rearranges operations that have not started. This is the same documented rule that governs every reschedule in the platform, applied unchanged to optimizer-driven changes, because the optimizer persists through the identical pipeline rather than a separate write path.

EDGEBIC by User Solutions treats completed work as fixed history everywhere, and the optimizer is no exception. This post explains how that preservation works, what happens to a partly-finished job, and why you can optimize mid-shift with confidence. For the wider actuals story, see what happens when you accept an optimized schedule, and for the pillar, the EDGEBIC optimizer guide.

Completed work is history, not a variable

When an operation is finished, its recorded actual start and end times are facts about what happened on your floor. A scheduling tool that rewrote those facts to make a plan look tidier would be worse than useless, it would be dishonest about your own history. So the platform draws a firm line: completed operations are immutable. A reschedule plans the future around them, it never edits them.

The optimizer inherits this line without exception. Whichever goal you choose and whichever engine you run, the completed rows are carried through the optimization unchanged and written back unchanged. The guarantee is not a special optimizer feature bolted on, it is the ordinary reschedule behavior, and the optimizer simply does not have a way around it.

What happens to an in-progress job

A job partway through its routing is the interesting case. Suppose a job's first two operations are complete and logged, and its next three have not started. The optimizer treats the two finished operations as fixed history and considers only the three remaining ones. It will not reschedule the job from scratch or second-guess the steps already run. The completed steps anchor the job, and the remaining steps are planned forward from where the job actually is.

This matters because it keeps the plan honest about reality. The optimizer is not planning an idealized job that starts fresh, it is planning the real job as the floor left it, with its history intact and its future open to improvement.

The same pipeline on Accept

The preservation is not only in the optimize step, it is in the write. When you Accept a proposal, it persists through the same pipeline as a normal Generate Schedule. That pipeline carries the actuals-capture and merge-guard machinery that protects completed rows on every reschedule the platform performs. Because the optimizer reuses it rather than writing directly, there is no path where an optimizer Accept could bypass the protections that keep your history intact. The audit row written at Accept records what changed, and completed work is not among it.

A validity check backs it up

Before any proposed plan can even reach persistence, a structural check inspects it. Among other things, it rejects any candidate that produced an inverted or impossible row, where an operation appears to end before it starts. This is a backstop, not the primary protection, but it means a modeling slip could never quietly corrupt a completed row on its way to Accept. The candidate would be rejected and your baseline kept. Read how Accept guards against other drift in staleness protection in the optimizer.

Why this lets you optimize mid-shift

The practical payoff is that you can run the optimizer at any time without fear of touching what has already been logged. Half a shift complete, a job underway, a machine that just finished a run, none of it is at risk. The optimizer looks only at the not-started work, which on most in-progress plans is still the bulk of the remaining schedule: the queue of jobs waiting their turn. Reordering that queue to feed machines better or protect due dates is exactly where optimization pays, and it is fully available even while the floor is running.

The comparison confirms it plainly. The move list shows changes only on the operations the optimizer actually touched, and completed or in-progress operations do not appear there because they did not move. You can read the list and see for yourself that nothing historical changed. See reading the optimizer move list.

How it relates to a normal reschedule

If you already trust the platform's reschedule to preserve completed work, you already trust the optimizer on this point, because they are the same mechanism. A reschedule with actuals plans the remaining steps forward from the last completed step and leaves history alone. The optimizer does the same, adding only a search over the ordering of the not-started jobs. There is no new risk surface. The difference between an ordinary reschedule and an optimizer run is the search for a better order, not a different treatment of your actuals.

The bottom line

The optimizer preserves completed and started work absolutely: finished operations pass through optimize and Accept byte-identical, an in-progress job keeps its history and only its remaining steps are planned, and Accept persists through the same actuals-protecting pipeline as any reschedule. A validity check rejects impossible rows as a backstop. This is the ordinary reschedule guarantee, unchanged, which is why you can optimize mid-shift without disturbing a single logged record. To try it, open the Optimizer tab in Schedule Jobs on a live plan and read the move list. Start at EDGEBIC.