What Happens When the CP-SAT Solver Is Not Installed

When the CP-SAT component is not installed, EDGEBIC falls back to the multi-run search rather than failing the run, so a proposal still appears but the badge reads best of N schedules tried instead of proven within a percentage of optimal. In EDGEBIC by User Solutions the engine selection in Options is a request; the badge on the result is the receipt. A mismatch between them is a deployment condition, not a defect, and every safety guarantee survives it.

The symptom

You set Options to Schedule and then Optimizer Engine to the mathematical solver. You run the optimizer. The result arrives normally, the comparison and move list look right, and the badge says something like best of six schedules tried in two seconds.

That badge belongs to the multi-run search. Selecting the solver did not take effect because the component is not present in this deployment, and rather than fail, the optimizer quietly used the engine it has.

Why the fallback is the right behavior

It helps to imagine the alternative. A planner presses Run before a shift meeting. An optional component is missing. Instead of a plan, a failure dialog appears, and the improvement they would have accepted is never produced at all.

The fallback keeps the useful part and gives up only the optional part. You still get a complete, constraint-respecting plan that was genuinely searched for, and you still get every protection. What you do not get is the mathematical certificate.

What you keep and what you lose

Read that table the right way round. The fallback costs you a claim, not a capability. The multi-run engine is an honest search that tries many job orderings through the real scheduler and keeps the best complete result, which is exactly what how the multi-run optimizer searches schedules describes.

There is even one respect in which the multi-run engine is broader: it reorders whole jobs whatever routing features they use, whereas the solver keeps some jobs exactly as the scheduler planned them and reports them as locked. That is a safety design in the solver, covered in how the optimizer locks features it does not model, but it does mean a solver run can sometimes change less.

Confirming the fallback rather than guessing

Three checks, in order of speed:

1. Read the badge. Best of N tried means multi-run. Proven within a percentage, or proven optimal, means CP-SAT.
2. Open Explain. Only solver results list locked jobs with per-job reasons such as multi-instance work center or parallel processing. No locked-job section is a strong signal.
3. Ask your administrator whether the CP-SAT component is deployed here. That is the actual fix, and it is an installation question rather than a configuration one.

Make the badge glance a habit on every run. It costs a second and it is the only place the truth is reported, which matters because the Options setting will keep showing your preference regardless.

What this is not

Worth ruling out explicitly, because teams tend to chase the wrong cause:

• Not a permission issue. Running and accepting are permission-controlled, but the engine choice is not gated that way.
• Not a data issue. Missing setup data hides the Least setup time goal, which is a different symptom entirely.
• Not a time budget issue. A short budget affects how much gets explored and can leave a wider gap, but it does not change the badge language.
• Not a licensing tier. This is a component present or absent in the deployment.

If your badge instead reads that there is nothing to optimize because some jobs use features not yet solver-optimized, that is the opposite situation: the solver is running, and every job in scope is locked. Open Explain for the per-job reasons.

While you wait for the component

Keep optimizing. The routine does not change, and neither does anything you have configured. When the component arrives, the same problem, the same goals and the same screen produce the same kind of proposal with better badge language, so nothing you build now is wasted.

Two habits are worth adopting in the meantime. Give the run a longer time budget when you want a harder search, since more alternatives get tried. And when someone asks whether the plan could be better, answer with what the badge actually supports: this is the best of the schedules we tried, not a proof. Overclaiming here is the one thing that would cost you the credibility the proof badge is meant to buy, which is why how a proven optimality gap builds trust treats the distinction as the whole point.

The takeaway

A multi-run badge after selecting the mathematical solver means the CP-SAT component is not installed in this deployment, and EDGEBIC deliberately falls back rather than fail the run. You keep the complete plan, the never-worse clamp, the untouched recorded work and the explicit Accept step; you lose only the bound and the gap percentage. Confirm by reading the badge and checking Explain for locked jobs, then treat it as an installation request. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with choosing the optimizer engine and the two layers of the EDGEBIC optimizer.