Why the Optimizer Returned the Same Schedule (And When That's Correct)

A schedule optimizer that returns your original schedule unchanged is not failing: it is honoring a never-worse rule that only replaces your plan when a candidate is strictly better under the goal you chose, and there are three legitimate reasons no candidate won. Either the baseline was already good (sometimes provably optimal), the jobs use features the solver deliberately holds fixed for safety, or the search did not get enough time. Each reason has a visible check, and one of them is actually the best news a planner can get.

The optimizer in EDGEBIC by User Solutions proposes a complete alternative plan, shows a side-by-side comparison, and persists nothing until you click Accept. When the proposal equals the baseline, here is how to read it. This post is part of the EDGEBIC troubleshooting guide; for the full feature tour, see the EDGEBIC optimizer guide.

First, Understand the Contract

EDGEBIC ships two optimizer layers, selectable per site:

Both layers end the same way: the candidate's measured results are compared directly against the baseline under your chosen goal. Not strictly better means the baseline is returned. That comparison is the never-worse rule, and it is enforced as a hard check, not assumed.

The consequence: a returned baseline is a defined, correct outcome, not an error state. The question is which of the following reasons produced it.

Reason 1: Your Schedule Was Already Good (Maybe Provably)

With few jobs, the multi-run layer tries every ordering. Three jobs means six orderings; if the engine's default order already wins, no alternative exists to find. At larger counts, a plan with zero late jobs gives an on-time-first goal literally nothing to improve, and the search can only tie.

With the mathematical solver the story gets better: the result carries an optimality gap. A gap of 0% on a returned baseline is a proof that no schedule beats yours under that goal. That badge is not a consolation prize; it is the answer every planner wants and few systems can give. For contrast, in the documentation's worked three-job example the same solver takes a baseline with 3 hours of lateness and returns a reordering with zero late jobs, proven optimal. When there is something to win, it wins it.

How to confirm: read the result panel. It reports the best challenger even when the challenger lost, and how close it came. A baseline that won by a wide margin over 24 tried schedules is a plan that has earned its place: the alternatives were evaluated and beaten.

What to do: accept the compliment. Optionally try a different goal preset; a schedule that cannot improve on due dates may still have setup hours or total span to recover.

Reason 2: The Jobs Are Locked for Safety

The exact solver models plain single-machine, sequential routings natively. A job whose routing uses anything beyond that (multi-machine instances, one-job-per-day rules, transit days, lot streaming, synchronized or independent parallel steps, alternate machines, or operator skill requirements) is locked: reproduced exactly as the standard engine scheduled it, still consuming its machine time so other jobs schedule around it honestly. Locking is why the solver can never emit an invalid plan for a capability it does not model; correctness comes before optimization scope.

If every job in the run is locked, the optimizer verifies the plan and changes nothing, and it says so plainly rather than claiming any optimality.

How to confirm: open the Explain panel on the result. It lists each locked job with its specific reason ("multi-instance work center," "lot streaming," and so on), so you can see exactly why the optimizer left a job alone.

What to do: nothing is wrong. If most of your work is locked, the multi-run layer is the better engine choice for now: it runs the full production engine per candidate, so every feature participates in every candidate schedule. Switching engines is a two-click setting and both layers keep the never-worse rule. If you picked the solver and the run behaved like multi-run anyway, a solver run that fell back to multi-run covers how to confirm the fallback.

Reason 3: The Search Ran Out of Time

Optimization is time-boxed: 10, 30, or 60 seconds, your pick. A short budget over a large job set evaluates fewer candidates, and an interrupted exact solve returns its best-so-far with a wider gap. Neither ever returns something worse than the baseline, but both can honestly come up empty.

How to confirm: the result records how many candidate schedules were evaluated and the elapsed time. A 10-second run that evaluated a handful of candidates over 40 jobs has not seen much of the space.

What to do: re-run at 60 seconds. Results are reproducible: the same inputs and settings produce the same plan, so a re-run with more time is a genuinely bigger search, not a dice roll.

Two Non-Reasons Worth Ruling Out

• "It ignored my constraints to find nothing." The opposite: every candidate in the multi-run layer is a complete real schedule from the same engine that runs production, so shift calendars, bottlenecks, and every configured rule hold in every candidate. Constraint compliance is why the search space is honest, and honest spaces sometimes contain no better plan.
• "It changed things without telling me." Nothing persists until Accept, completed work passes through untouched, and an accepted result writes a full audit record with the goal, the numbers before and after, and the explanation. A returned baseline plus Discard leaves the database byte-identical.

The Practical Checklist

1. Read the badge: "best of N tried" (heuristic search) versus "proven within X%" (mathematical proof). A 0% gap means stop; you are done.
2. Open Explain and count locked jobs. Mostly locked: switch to the multi-run engine or accept the verification.
3. Check the goal preset. Zero late jobs plus an on-time goal equals nothing to win; try least-setup or fastest-finish.
4. Raise the time budget to 60 seconds and re-run.
5. If setup time is your real target, populate the sequence-dependent setup matrix first; the least-setup goal stays hidden until changeover data exists, and with it the solver can recover hours the standard engine cannot see. The paint shop sequencing example shows what that looks like with real numbers.

An optimizer you can trust to say "your plan stands" is the same optimizer you can trust when it says "this plan is better." The two claims are one contract.