What Is a Job-Level Feature Lock in Scheduling Optimization?

A job-level feature lock pins a job to its standard-engine plan whenever the job uses a feature the mathematical solver does not yet model natively, reproducing that job exactly as the everyday engine scheduled it while the solver rearranges only the fully-modeled jobs around it. It is the safety rule that lets a rigorous solver run on a real shop without ever producing a plan that violates a capability it does not understand: the delicate synchronized jobs stay exactly where the foreman put them, and only the simple jobs get reshuffled.

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

The Problem It Solves

A mathematical solver optimizes only what it can model. Modeling every scheduling feature perfectly (multiple instances, synchronized parallel machines, lot streaming, transit time, operator skills, and more) is a large undertaking that grows one feature at a time. Until a feature is fully modeled, the solver has no safe way to move a job that depends on it, because any rearrangement it invents could break the feature's real-world rules.

The naive answer is to refuse to optimize any shop that uses those features, which rules out most real plants. The feature lock is the better answer: optimize what you safely can, and freeze the rest in place.

How It Works

Before the solver runs, each job's routing is inspected. If it uses any capability the model does not yet optimize natively, the job is marked locked and given a readable lock reason naming the feature responsible.

A locked job is not removed and not ignored. It is reproduced in the optimized plan exactly as the standard engine scheduled it, every operation pinned to its original slot, still consuming that machine's capacity. The solver then optimizes only the unlocked jobs, and it does so against the honest picture the locked jobs create: the capacity they hold is real, so the movable jobs are arranged around genuine load, not a fantasy of empty machines.

Because a locked job can never be rearranged by the solver, the solver can never emit an invalid plan for a feature it does not model. Safety is structural, not hoped for.

A Concrete Example

Consider a shop running twenty jobs. Twelve are plain sequential routings on single-instance machines. Eight use synchronized parallel drill heads and lot streaming.

When the optimizer runs, the eight complex jobs are locked, each tagged with its reason ("parallel processing," "lot streaming"). They keep their standard-engine schedule and their capacity footprint. The solver then works on the twelve sequential jobs, reordering them to pull a tight due date forward and trim changeover, fitting them around the fixed load the eight locked jobs impose. The result reports twelve jobs optimized and eight locked, so the split is plain to see. Nothing about the delicate synchronized work was touched, and nothing invalid could have been produced.

How EDGEBIC Uses It

In EDGEBIC, the feature lock is one of the optimizer's core safety contracts. When the mathematical solver runs, it analyzes each job's features first and locks any job that uses multiple instances, a one-per-day machine, transit days, lot streaming, parallel processing, alternate work centers, work center groups, operator skills or pins, and in some cases the sequence-dependent setup matrix. Each locked job's reason is shown in the optimizer's explanation view, and the result reports optimized and locked counts as honesty figures.

The lock composes with the optimizer's other guarantees. Locked jobs are copied from the standard engine verbatim, then the whole candidate still passes the never-worse clamp before it can be proposed, and nothing persists until you Accept. This is also why the optimizer can run as a safe sidecar: the engine's plan for locked jobs is the ground truth the solver builds on. For the full picture, see the optimizer guide and the optimizer goals and presets.