What Is a Scheduling Policy? Definition and Examples

A scheduling policy is the site-wide rulebook that governs how the scheduling engine behaves across every run: a single set of defaults, one per installation, covering choices like how partial completions are handled, whether new jobs schedule forward or backward by default, and which optimizer the comparator uses. The engine reads the policy at the start of each run and applies it uniformly. The plain analogy is the shop's standing rulebook: "operators' close-out stamps are trusted unless flagged," written once and followed by every job.

This entry is part of the EDGEBIC glossary; see the manufacturing glossary for the wider vocabulary and the scheduling mode definition for the per-run scope that a policy sits above.

How a Scheduling Policy Works

Every scheduling run makes hundreds of decisions, but a handful of them are the same every time and should not be re-argued per job. Whether a short completion writes off its missing hours or reschedules them. Whether a new order aims to start as soon as possible or to finish just in time. How far ahead the engine may search for capacity. Which optimizer runs. These are shop-level standing decisions, and the scheduling policy is where they live.

There is exactly one policy row per installation. The engine reads it once at the start of a run and passes it through the whole pipeline; it does not change the policy while scheduling. That single-source design is what makes the plant behave consistently: two runs a week apart follow the same rules, and every planner works from the same defaults.

A policy is deliberately narrow. It holds the decisions that are genuinely site-wide, not the per-job details (a job's quantity, due date, or routing) that belong to the order itself. Some policy defaults can be overridden on an individual order where that makes sense, but the policy is always the starting point.

What a Scheduling Policy Controls

The core standing decisions a policy carries include:

• Partial-completion handling. When an operator marks a step complete but logs fewer hours than planned, the policy decides what happens to the gap. It can trust the operator's end stamp and write the missing hours off, forward-shift the missing hours onto a fresh future slot so no work is lost, or trust the stamp unless a specific step is flagged for rigorous tracking. The default forward-shifts the remainder, matching standard scheduling systems.
• Default scheduling direction. New orders can default to forward (start as soon as possible) or backward (finish just in time against the due date). The policy sets the site default; individual just-in-time orders can be flagged the other way.
• Capacity search horizon. How many days forward the engine may walk looking for open capacity before it gives up on a job. On a fully booked bottleneck, this is the leash that stops the search running forever.
• Optimizer engine. Which optimizer the schedule comparator uses when a planner asks it to improve a plan.

Changing a policy default takes effect on the next run with no restart, and (for direction) applies only to new orders, leaving existing ones untouched.

The scope of a policy change is worth understanding, because it is not retroactive in the way you might expect. Flipping the site-wide default direction from forward to backward does not right-align every order already in the system; it changes the default that new orders inherit. Orders already created keep whatever direction they were given. This is deliberate: a policy change should steer future planning without silently rewriting commitments the shop has already made. When you do want an existing order to follow a new rule, you change that order, not the policy.

A Concrete Example

A custom job shop treats the operator's close-out as ground truth: when someone stamps a step done, it is done, and any unlogged hours are simply not there. A make-to-stock plant next door wants the opposite: if a step was planned for eight hours and only six were logged, the remaining two should be rescheduled so the work is not quietly lost.

Both behaviors come from one policy setting. The job shop sets partial-completion handling to trust the actual end. The make-to-stock plant sets it to forward-shift the remaining hours. Neither has to make that decision per job; the policy applies it to every close-out automatically. If the make-to-stock plant later wants to track only certain critical operations rigorously, it can switch to the trust-unless-flagged option and flag those specific steps, leaving the rest closed on the operator's stamp.

How EDGEBIC Applies a Scheduling Policy

In EDGEBIC, the scheduling policy is a single settings record edited under Options and Schedule (also referred to as Schedule Policy). Partial-completion behavior, the default scheduling direction, the capacity search horizon, and the optimizer engine all live there. The engine reads the record at the start of every Generate Schedule run, so a change you save applies to the next run without restarting the application.

Because the policy is a shop-level rulebook, most planners set it once during setup and revisit it only when the way the plant runs genuinely changes. For the step-by-step on choosing your defaults, see how to configure a scheduling policy and how to set the default scheduling policy.

Two of the policy's most important defaults get their own treatment: the default direction connects to forward versus backward scheduling, and the per-run scope the policy governs is the scheduling mode. For a job-level exception to one policy default, see the schedule-at-utilization setting.

A scheduling policy is the difference between a plant that schedules by consistent rules and one that re-decides the same questions on every job. Set it once to match how your shop actually runs, and every run inherits it.