Why the EDGEBIC Optimizer Is a Sidecar, Not a Replacement

The EDGEBIC optimizer is a sidecar: it runs beside the scheduling engine, never inside it. The engine that plans your jobs today keeps making every placement decision exactly as it always has. The optimizer proposes a complete alternative plan, shows it next to your current one, and writes nothing until you Accept. It touches the engine through exactly one seam, and even that seam only changes the order in which jobs are considered, not how any of them are scheduled. This architecture is the reason optimization is safe to run on a schedule you already trust.

EDGEBIC by User Solutions built optimization this way on purpose. A scheduling engine that has proven itself on real plants carries hard-won correctness in every path: rescheduling, preserving completed work, mirroring parallel machines. Injecting an optimization loop into that engine would put all of it at risk. The sidecar avoids that entirely. For the related concept, see what is an optimizer sidecar in scheduling.

The engine keeps its job

The base scheduler plans one job at a time, most important first, placing each operation at its earliest feasible slot while respecting finite capacity. That logic is battle-tested and full of subtle correctness that took years to get right. The sidecar design treats it as a black box that must not be disturbed.

In the sidecar model, the engine plays three roles at once:

• Default scheduler. When you are not optimizing, the engine runs exactly as before.
• Starting point. Every optimizer run begins by having the engine produce its normal plan, which becomes both the seed the optimizer builds on and the floor it must beat.
• Fallback. If the optimizer cannot find something better, or the mathematical solver errors out, the engine's own plan is what you keep.

Nothing about running the optimizer changes any of these roles. The engine is doing the same work whether or not you ever open the Optimizer tab.

The one seam

An optimizer that never changed anything would be useless, so there is exactly one point where it influences the engine: it can supply a different global order in which the engine considers jobs. The engine still decides every placement, still respects every constraint, still handles every routing feature the same way. The only thing that changes is the sequence in which jobs are fed in.

That single point of contact is the entire engine-side footprint of the whole optimizer feature. When the optimizer is not driving, the engine sorts jobs its own way (priority, then start time, then due date) exactly as it always has. When the optimizer is driving, it hands the engine a candidate order, lets it schedule normally, and measures the resulting plan.

This is why every candidate plan is a real schedule. It is produced by the same engine that runs your plant, so it can only ever be an arrangement the engine could already produce. There is no separate scheduling logic to disagree with your engine, no new constraint handling to get wrong.

Nothing writes until you Accept

The second half of the sidecar promise is that the optimizer's proposals live only in memory until you decide. A run computes a proposal, holds it on the Optimizer tab under a private token, and touches nothing in the database. You review the verdict, the key performance indicator deltas, and the changes-only move list. Then you choose:

• Accept writes the proposal through the same persistence pipeline as a normal scheduling run, with the same protections for recorded work, and records one audit entry.
• Discard drops the proposal. The database is byte-for-byte untouched, as if you had never run it.

Because Accept is the only write path, the worst case of trying the optimizer is that you Discard and lose a few seconds. Learn what Accept does in what happens when you accept an optimized schedule.

A worked example of the safety in action

Suppose you run the mathematical solver on a busy week and, partway through, the solver hits an internal error on a hard subproblem. In a design where the optimizer replaced the engine, that error could leave you with no plan at all. In the sidecar design, the error is caught and logged, and the never-worse clamp returns the engine's own plan. You see a normal result: your current plan stands. Selecting the mathematical solver can never break a scheduling run.

Now suppose the solver succeeds but proposes a plan that, once measured, is not actually better than the engine's plan under your goal. The clamp catches that too: the engine's plan is returned and the verdict tells you your current plan survived the challenge. In both cases the engine's plan is the floor, exactly as the sidecar architecture guarantees. This is the same clamp described in what the never-worse guarantee means for planners.

Why not just build optimization into the engine?

It is a fair question. The answer is risk versus reward. Building an optimization loop into the scheduling engine would entangle it with every reschedule path, every actuals-preservation rule, and every parallel-machine behavior. A change to make optimization work could quietly break a reschedule that had worked for years. The sidecar keeps those concerns separate: the engine stays exactly as trusted as it was, and the optimizer is a search wrapped around it.

This separation also makes the two optimizer layers interchangeable. The multi-run search and the mathematical solver both plug into the same seam and are measured against the same engine floor. Switching between them in Options is safe precisely because neither one is inside the engine.

The engine handles the hard cases the optimizer would fumble

There is a second reason the sidecar reuses the engine rather than reimplementing scheduling: the engine already handles cases a from-scratch optimizer would struggle to model correctly. Multi-instance work centers, one-per-day machines, transit days between operations, lot streaming, and parallel processing all carry subtle rules the engine has encoded over years. When the optimizer feeds the engine a job order and lets it schedule, all of those rules are honored automatically, because the engine is the thing enforcing them.

The mathematical solver models only the cases it can prove it models correctly, and it locks any job whose routing uses a feature it does not yet handle natively, reproducing that job exactly as the engine scheduled it. That lock is the sidecar principle applied at the job level: where the solver is unsure, it defers to the engine rather than guess. The result is that even the most feature-heavy dataset is safe to optimize, because the parts the solver does not model are simply left as the engine planned them. Read how that plays out in locked jobs and the never-worse guarantee.

What the sidecar means for you

For a planner, the sidecar design translates into a few practical facts:

• Trying the optimizer is free. It cannot regress the plans your engine already makes.
• Every proposal is buildable. It came from your engine, so the floor can physically run it.
• You are always in control. Nothing changes until you Accept, and Discard leaves everything exactly as it was.
• The solver is optional. If the mathematical component is not installed, EDGEBIC falls back to the multi-run search rather than fail.

For the broader optimizer picture, see the EDGEBIC optimizer guide, how mathematical optimization improves a schedule, and the wider view of production schedule optimization. To explore the platform, visit EDGEBIC.

The sidecar keeps the roadmap safe too

The sidecar design pays off over time, not just on any single run. As EDGEBIC teaches the mathematical solver to model more features natively, freeing jobs that are locked today, each new capability is added beside the engine and measured against it, never inside it. A newly modeled feature must first prove that any plan the engine produces is also valid in the solver's model. If the two ever disagree, that is caught before the feature ships, because the engine remains the reference the solver is checked against.

For a planner, this means the optimizer can grow more capable without ever putting the scheduling you rely on at risk. Today a job with parallel processing is locked and reproduced exactly; a future release may optimize it natively, and when it does, it will do so only after proving it agrees with the engine on every case. The engine you trust stays the anchor through every expansion. That is the long-run reason the sidecar is more than an implementation detail: it is what lets the feature improve safely for years rather than freeze the day it shipped.

The bottom line

The EDGEBIC optimizer is a sidecar because a scheduling engine you trust should not be rebuilt to add a feature. The engine keeps planning your jobs, the optimizer proposes alternatives by feeding it different job orders through one seam, and nothing reaches the database until you Accept. Every candidate is a real, buildable schedule, the engine is always the floor and the fallback, and a solver error can only ever return you to the plan you already had. That is what makes optimization safe to try on a live schedule, and it is a deliberate architectural choice rather than a happy accident.