What Is the Never-Worse Clamp in Scheduling Optimization?

The never-worse clamp is a mandatory check that scores an optimized schedule against the plan you started with and returns the original plan unless the optimized one strictly beats it, so running the optimizer can only improve your schedule or leave it unchanged, never make it worse. It is the guardrail that lets a shop press the optimize button on a live schedule without fear: the worst outcome is the plan already in hand.

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

The Problem It Solves

A scheduling optimizer, given a limited time budget, does not always land on the best possible plan. It lands on the best plan it could reach before the clock ran out. Left unguarded, that plan can occasionally be worse than the schedule a planner produced by hand, and a single embarrassing regression is enough to make a shop stop trusting the tool entirely.

Feeding the solver a good starting point (a warm start) helps, but it is not enough. The hint is advisory: the solver may wander away from it and finish on something worse. Something has to check the final answer before it reaches you.

How It Works

After the solver produces a candidate, the clamp scores that candidate and the baseline side by side, using the exact goal you selected (protect due dates, minimize total finish time, minimize changeover, minimize disruption). Then it applies one rule:

• If the candidate is strictly better on that goal, return the candidate.
• If the candidate ties or loses, return the baseline, and report that the baseline was retained.

The comparison is enforced in code, not left to trust. A warm-start hint alone is advisory; the clamp is what turns "the optimizer usually helps" into "the optimizer can only help." Both the multi-run search and the mathematical solver route through the same clamp, so the guarantee holds regardless of which engine you run.

A Concrete Example

Suppose your current plan finishes with three jobs one day late. You run the optimizer with the goal set to protect due dates. The solver explores orderings and returns a candidate that finishes with only one job late. The clamp scores both, sees one late beats three late, and returns the improved plan.

Now suppose a different run explores a candidate that trims total finish time by an hour but pushes a fourth job past its due date. Against the due-date goal, that candidate is worse, so the clamp discards it and returns your original plan unchanged. You lost nothing. The optimizer simply reports that it could not beat the baseline this time, which is honest and safe.

How EDGEBIC Uses It

In EDGEBIC, the clamp is one of the optimizer's non-negotiable contracts. Every run computes the baseline first with the untouched scheduling engine, then runs the solver, then clamps. When the baseline wins, the result is labeled as baseline-retained and nothing is proposed for you to accept.

The clamp works together with two other safeguards. Nothing the optimizer produces is written to your live schedule automatically: a run is held in memory as a proposal until you press Accept, and the proposal is re-checked against the current data at Accept time so a colleague's reschedule cannot be silently overwritten. And jobs that use features the mathematical model does not yet handle natively are reproduced exactly as the standard engine scheduled them, a job-level feature lock that keeps every plan valid. Together these rules mean optimization is additive: you keep your gains, you absorb no losses. For how the optimizer sits beside the standard engine, see the optimizer guide and the optimizer goals and presets.