The Optimizer Will Not Improve a Job I Know Can Move

When the optimizer leaves one specific job exactly where it is, that job's routing almost always carries a feature the exact solver does not model natively, so the job is locked on purpose and reproduced exactly as the standard engine scheduled it. This is a correctness safeguard, not a defect, and the Explain dialog names the reason for that job.

EDGEBIC by User Solutions runs its exact solver as a sidecar that natively optimizes plain single-machine, sequential jobs. A job whose routing touches anything beyond that is locked: reproduced verbatim, still consuming its machine capacity so the optimizable jobs schedule around it honestly. Locking is why the solver can never emit an invalid plan for a capability it does not understand. This post is the single-job version of the diagnosis; it sits in the EDGEBIC troubleshooting guide and is the companion to why the optimizer returned the same schedule, which covers the whole-run case, and to the optimizer guide.

First, Open Explain and Read the Job's Reason

The optimizer result carries an Explain dialog that lists each locked job with its specific reason, and the result reports an optimized-job count and a locked-job count. Open it and find your job. The reason tells you exactly which feature held it fixed, and everything below is just interpreting that reason. If the job is in the locked list, the solver did not fail to improve it; it deliberately did not touch it.

The Features That Lock a Job

A job is locked when its routing uses any of these, because the exact solver does not yet optimize them natively:

Any one of these on any step of the job's routing is enough to lock the whole job. The lock protects correctness: the solver never guesses at a feature it does not model.

Cause 1: The Routing Uses an Unmodeled Feature (the Lock Is Correct)

The job you expected to move uses one of the features above, so it is locked and reproduced exactly.

How to tell: the Explain dialog lists the job with one of the reasons in the table.

Fix: decide among three honest options. Switch the optimizer engine to the multi-run layer, which runs the full production engine for every candidate so every feature participates and the job can actually be moved. Or, if the locking feature is not actually needed on that routing (an alternate machine you never use, a transit day set to zero purpose), remove it and re-run so the job becomes optimizable. Or accept the lock, because the standard engine's placement of that job is already valid.

Cause 2: Most of the Dataset Is Locked (Wrong Engine for This Plant)

If many jobs are locked and the solver barely moved anything, the plant's routings lean on features the exact solver locks, and the searchable space is small.

How to tell: the locked-job count is high relative to the optimized-job count.

Fix: switch to the multi-run engine for this dataset. It runs the full production engine per candidate ordering, so machine pools, parallel steps, lot streaming, and alternates are all honored in every candidate, and locked jobs are not a concept there. The engine choice is a per-site setting, and both layers keep the never-worse guarantee, so the switch cannot degrade the plan. The multi-run layer is described in the optimizer goals and presets explained.

Cause 3: The Goal Has Nothing to Win on That Job

Even an optimizable job will not move if the chosen goal has nothing to gain from moving it. A job already on time under an on-time-first goal is a tie, not a loss.

How to tell: the job is not in the locked list, but the goal preset has no lever on it, for example an already-on-time job under an on-time goal.

Fix: try a different goal preset. A job that cannot improve on due dates may still have setup hours or total span to recover under a least-setup or fastest-finish goal. The whole-run version of this is covered in why the optimizer returned the same schedule.

The Reconciliation, in Order

1. Open Explain and check whether the job is in the locked list.
2. Read the lock reason to identify the feature on its routing.
3. Switch to the multi-run engine if you want that feature optimized, since it runs the full engine per candidate.
4. Remove the feature only if it is genuinely unused on that routing.
5. If the job is not locked, try a different goal preset, because the current goal may have nothing to win on it.

Prevention

• Read the optimized-versus-locked counts on every result, so a low optimized count is expected rather than surprising.
• Match the engine to the dataset. Feature-heavy routings favor the multi-run layer; plain sequential work favors the exact solver.
• Keep routings honest, so an unused alternate or a pointless transit day does not lock a job you wanted optimized.
• Trust the lock. A locked job is a valid plan the solver chose not to risk rewriting, not a job it could not schedule.

A result that appeared to make the schedule worse, rather than leaving it unchanged, is covered in the optimizer made my schedule worse, which walks through the never-worse guarantee.