Reading the Optimizer Move List

The optimizer move list is the changes-only view of a proposal: one row per operation that actually moved, showing the kind of change, the old and new start, the shift in hours, and a plain reason chip. Operations that did not move are never listed. This makes reviewing a proposal fast and honest at the same time: you see exactly what the optimizer would change if you Accept, and the absence of a row is itself confirmation that an operation stayed put. Combined with the key performance indicator table, the move list lets you judge a proposal on both its outcome and its specific disruptions before committing to anything.

EDGEBIC by User Solutions builds this list once per run and shows it in the Optimizer tab alongside the verdict and the KPI deltas. This post walks through every column and change kind so you can read a proposal with confidence. For the numbers that sit beside the move list, see how the optimizer scores a schedule, and for what Accept does with the moves, what happens when you accept an optimized schedule.

What a move row contains

Each row describes one changed operation. The columns are:

Reading left to right, a row tells a complete little story: this operation, currently here, would move to there, that many hours in that direction, for this plainly stated reason. You do not need to cross-reference anything to understand a single move.

The four kinds of change

The kind label tells you at a glance what sort of move you are looking at.

A time shift is the most common. The same operation, on the same work center, moves to a different start. On a reordering run this is the bulk of the list, because the optimizer's main lever is the order jobs are taken, and reordering shifts start times.

A work center change means an operation moved to a different machine. This appears when a step has alternate work centers available or when the reorder freed a better machine for it. Read these with a little more attention, since they change where work runs, not just when.

Added means the proposal contains an operation the baseline did not, and removed means the baseline had one the proposal drops. These are less common on a straightforward reorder and worth a look when they appear.

Why unchanged operations are hidden

A proposal on a plan with hundreds of operations may leave most of them exactly where they were. Listing every unchanged row would bury the few that matter under a wall of noise. So the move list shows only the differences, which is what makes review quick: read the handful of changes, confirm each makes sense, and decide.

The hiding also serves a quiet safety purpose. Because completed and unchanged operations do not appear, the move list doubles as confirmation that nothing you did not expect to move has moved. If your in-progress morning work is not in the list, it did not change, which it never would, since completed and started work is preserved. A short move list on a big plan is a normal, healthy result.

Reading the list against the KPI table

The move list answers "what changed," and the KPI table answers "was it worth it." Read them together. A dozen time shifts that drop weighted tardiness to zero and add two on-time jobs is a clear win: small disruption, large delivery gain. A dozen moves that barely change the numbers is a proposal you can Discard without cost. The move list lets you weigh the specific disruptions against the measured improvement, which is the judgment Accept asks you to make. Each Change cell in that table spells its direction out in a word as well as an arrow, for the reason set out in why optimizer changes show an arrow and a word.

The reason chips help here too. A row reading starts 4.0h earlier next to a job you know was at risk tells you immediately why the plan improved. The chips are templated summaries, not free text, so they read consistently across every run.

Acting on what you see

Once you have read the list, you have three honest choices. Accept persists the whole proposal through the standard pipeline, moves included, and writes an audit record. Discard drops the proposal and leaves your plan byte-identical. Or, if the numbers are good but one specific move bothers you, note it, Discard, adjust the relevant job or work center, and rerun. Nothing in the move list is applied piecemeal: a proposal is Accepted or Discarded as a whole, which keeps the never-worse guarantee intact across the plan. For that guarantee, see what the never-worse guarantee means.

The bottom line

The move list shows one row per changed operation, with its kind, old and new start, the shift in hours, and a plain reason chip, and it hides everything that did not move. That focus makes review fast and confirms at a glance that unchanged and completed work stayed put. Read the moves against the KPI table to weigh disruption against improvement, then Accept the whole proposal or Discard it at no cost. To see it, run the optimizer on the Optimizer tab in Schedule Jobs and open the changes list beneath the verdict. For the wider picture, read the EDGEBIC optimizer guide, and explore the platform at EDGEBIC.