The Safety Gate Every Optimized Schedule Must Pass

The safety gate is the set of validity checks every optimized plan must clear before EDGEBIC will show it to you: dates in order, no dropped jobs, completed work untouched. The optimizer may explore rough ideas internally, but a candidate reaches your comparison screen only after it proves it is a legal schedule. A proposal is never trusted blindly.

EDGEBIC by User Solutions runs the optimizer as a sidecar beside the proven scheduling engine, and a sidecar is exactly the kind of second path that needs its own guard rail. The safety gate is that guard rail. It sits alongside the never-worse scoring as an independent check on structure rather than quality. For the full optimizer picture, see the EDGEBIC optimizer guide.

Two questions, two guarantees

When the optimizer produces a plan, there are two separate questions to answer, and EDGEBIC answers them with two separate mechanisms.

The first question is "is this plan better?" That is quality, and it is settled by scoring the candidate against your baseline with one shared calculator. If the candidate does not beat the baseline on the goal you chose, the optimizer keeps the baseline. That is the never-worse guarantee, covered in the never-worse guarantee in schedule optimization.

The second question is "is this plan even valid?" A schedule can score well on a goal and still be structurally broken, so quality alone is not enough. The safety gate answers this second question independently. A candidate has to be both valid and no worse before the optimizer offers it. Keeping the two checks separate is deliberate: a plan that is legal but no improvement is discarded by the scoring, and a plan that looks like an improvement but is illegal is discarded by the gate.

What the gate actually checks

The safety gate runs a handful of structural tests on the decoded candidate, the real schedule the plan would become if you applied it. These are the same integrity rules a schedule from the main engine is expected to satisfy.

The gate confirms the plan is not empty, so the optimizer cannot hand back nothing. It confirms no operation has an end that falls before its start, the inverted-date fault that would make a row nonsensical. It confirms no job has been silently dropped, so every order you started with is still present in the proposed plan. And it confirms that completed and started work is preserved exactly, so history is never rewritten. Each check is simple on its own; together they certify the plan is a schedule you could actually run.

The gate deliberately does not assert some things that look like errors but are legitimate. Certain synchronized operations genuinely consume capacity in ways that would trip a naive over-booking check, so the gate does not flag those as faults. The point is to catch real corruption, not to reject valid but unusual arrangements.

Why the decoded plan, not the model

The most important design choice in the gate is what it inspects. It checks the decoded schedule, the plan translated back into real operations with real start and end times, not the optimizer's internal representation.

This matters because the internal model is an approximation. It compresses calendars, rounds time into fine ticks, and simplifies constraints to make the math tractable. A candidate can look perfectly clean inside that model and still decode into something with a structural flaw once every real detail is reapplied. By running the checks on the decoded plan, the gate measures the thing you would actually apply, so any gap between the model and reality is caught rather than hidden. It is the same reasoning that makes the never-worse clamp score the decoded plan too.

Defense in depth, not a single wall

Today the optimizer's safety comes mostly from structure. The engines are built so that a plain sequential job is rearranged only in ways that stay legal, and any feature the optimizer does not model natively is locked to the schedule the proven engine already produced. That locking is covered in how the optimizer locks features it does not model, and it means the optimizer rarely has the opportunity to produce something invalid in the first place.

The safety gate is the second wall behind that first one. Even with the locking in place, the gate re-checks every candidate, so a future modeling change that introduced a bug would be caught before it reached you rather than after. That is what defense in depth means: the system does not rely on any single mechanism to keep you safe. The locking prevents most bad plans from forming, and the gate stops any that slip through from ever being shown.

What you never have to worry about

The practical payoff is a short list of things you never have to check by hand. You do not have to scan an optimized plan for a job that vanished. You do not have to look for an operation whose end time precedes its start. You do not have to confirm that the work your floor already finished is still recorded as finished. The gate has already verified all of it, because a plan that failed any of those checks was discarded and never offered.

Combined with the deferred Accept, where nothing is written until you choose to apply it, this makes the optimizer safe to run on a whim. Whatever it shows you has already cleared the gate, and even then it only lands when you say so. You can explore freely, knowing that both the validity and the timing of any change stay under your control.

The bottom line

The safety gate is the reason you can trust an optimized plan without auditing it: every candidate must prove it is a legal schedule, no dropped jobs, no inverted dates, no rewritten history, before the optimizer will show it. It checks the decoded plan rather than the internal model, it runs independently of the never-worse scoring, and it sits as a second wall behind the feature locking that keeps most bad plans from forming at all. Quality and validity are two questions, and EDGEBIC answers both before a plan reaches you. Explore the platform at EDGEBIC.