What Is an Optimizer Sidecar in Scheduling?

An optimizer sidecar is an optimization component that runs beside the standard scheduling engine rather than being built into it: the everyday engine still produces every plan, and the optimizer sits alongside, using that plan as a starting point, proposing a better one, and handing it back for the planner to accept or discard. It is a navigator suggesting a faster route while the driver keeps driving: the car's controls are never touched.

This entry is part of the EDGEBIC by User Solutions glossary; the broader dictionary lives in the manufacturing glossary.

Why a Sidecar and Not an Overhaul

A production scheduling engine is not a small thing. It handles shifts and calendars, multiple machine instances, parallel and synchronized operations, lot streaming, transit time, sequence-dependent setup, and dozens of edge cases that only surfaced after years of real shop use. That accumulated logic is the reason the plans it produces are trustworthy.

Turning that engine into an optimizer by rewriting its core would put every one of those hard-won behaviors at risk. The sidecar pattern refuses the trade. Instead of changing the engine, the optimizer is placed next to it. The engine remains three things at once: the default scheduler that produces plans, the warm-start seed the optimizer improves from, and the fallback the result is measured against.

How It Works

The engine and the optimizer stay separate, and they communicate through one deliberately narrow seam: the optimizer can supply the global order in which jobs are scheduled for a given run. That is the only hook.

The multi-run search layer uses this seam directly. It feeds the engine different candidate job orderings (earliest due date, shortest processing time, longest processing time, critical ratio, exhaustive orderings for small job counts, and seeded shuffles), lets the untouched engine schedule each one, and scores every resulting plan. The mathematical solver layer models the problem formally on a compressed time axis, warm-starts from the engine's plan, and returns a plan plus a proof of how close it sits to the theoretical best.

Whichever layer runs, the engine's own scheduling behavior is unchanged. Optimization is layered on top through that single seam, not stitched through the engine's internals.

A Concrete Example

Imagine a shop that has run the standard engine for a year with no complaints. The plans are solid; the floor trusts them. Now the shop wants to squeeze out late deliveries.

With a sidecar, nothing about the trusted engine changes. The planner opens the optimizer, which asks the engine to produce its normal plan, then explores alternate job orderings against that plan and returns the best improvement it found. If the planner never opens the optimizer, every schedule is exactly what it was before. If they do, the engine still did all the actual scheduling; the optimizer only chose a better order to feed it and proved the result was an improvement before proposing it.

How EDGEBIC Uses It

In EDGEBIC, the sidecar rule is architectural: all optimization runs beside the standard scheduling engine, and the engine is never modified to serve it. The one sanctioned seam is the injectable job-ordering hook; with no optimizer attached, the engine sorts jobs exactly as it always has.

That containment enables the rest of the optimizer's safety contracts. Nothing is written automatically: a run is held as a proposal until you press Accept. The result can only help, because a never-worse clamp compares it against the engine's plan and keeps the engine's plan if the candidate does not strictly beat it. And jobs using features the mathematical model does not yet handle natively are reproduced exactly as the engine scheduled them. You can even choose which optimizer implementation runs, and if the mathematical solver is not available in your build, the selector quietly falls back to the multi-run search, so choosing it can never break scheduling. The mathematical solver measures the plant week in working-hour ticks, hundredths of an hour on a calendar with closed time cut out, so it reasons in whole numbers rather than floating point. For the full pipeline, see the optimizer guide and where it fits in the scheduling engine guide.