How a Scheduler Decides Which Job Runs First

A finite capacity engine decides which job runs first by sorting every order before it places a single operation, using three keys in strict order: priority, then start date, then due date. The lowest priority number gets the first claim on contested machine time; ties break by the earlier release date, and then by the earlier due date. EDGEBIC by User Solutions applies this sort deterministically, which means the same inputs always produce the same sequence, and any change in the schedule traces directly back to a change in the data. Understanding the sort answers most "why did that job jump the queue?" questions before you ever open the Gantt.

The sort happens once, up front

Sequencing is not decided operation by operation as the engine goes. Before any placement, the engine orders the whole job list, then processes jobs in that order, each getting first claim on the capacity the earlier jobs left behind. The sort keys, in order:

ORDER BY Priority ASC, StartTime ASC, DueDate ASC

Priority is the primary, user-visible key. Lower integer means higher priority, matching the drag-to-reorder convention in the orders grid. Start date and due date are tie-breakers, so two jobs of equal priority still schedule in a stable, meaningful order rather than at random.

Why deterministic tie-breaking matters

There is no randomness anywhere in the sort. That property is worth more than it first appears. If you run the same data twice you get the same schedule twice, so a difference between two runs is never noise; it always points to a real change in the inputs: a new order, an edited due date, a logged actual. When a planner asks "why did the plan move?" the answer is always in the data, never in the engine's mood.

This is the opposite of a system that shuffles ties, where the same inputs can yield different plans and you can never fully trust a diff. Determinism is what makes a schedule auditable.

A worked example

Three orders enter a fresh plant:

The sort produces MO-102, MO-101, MO-103. MO-102 is first because priority 1 beats priority 2. MO-101 and MO-103 both sit at priority 2, so the start-date tie-break puts MO-101 (June 15) ahead of MO-103 (June 16). Every job then claims machine time in that order, and MO-102's operations get first pick of contested slots.

Change nothing but MO-101's priority to 1 and it jumps ahead of MO-102 only if its start date is earlier or equal and its due date wins the tie; otherwise the two priority-1 jobs sort between themselves by start date. The rule composes cleanly, one key at a time. Raising a priority mid-week is also how a rush order gets slotted in, and because started and completed work is preserved while only the unstarted future reflows, you can see exactly which jobs slip: how a scheduler absorbs a rush order walks through that.

The one override: producer before consumer

There is a single case where priority does not decide first place. When make-to-stock netting is active, a job that builds stock is sorted ahead of any job that consumes that stock in the same run, even if the consumer has higher priority. Without this, a priority-1 make-to-order job could run first, find zero on hand, and schedule its full quantity from raw material, while the stocking build produced inventory nobody consumed. The producer-first rule keeps netting honest, and it applies only to that relationship; everything else still sorts by priority, start date, then due date.

Where dispatch rules and the optimizer fit

The three-key sort is the engine's standard sequencing. It is not the only sequence worth considering. Classic dispatch rules such as earliest due date, shortest processing time, and critical ratio each order jobs by a different logic, and the best sequence for minimizing lateness is genuinely hard to find because it is an NP-hard problem.

This is where the optimizer sidecar comes in. It re-runs the same engine under different global job orderings, including earliest due date, shortest and longest processing time, critical ratio, and seeded shuffles, scores each complete schedule, and proposes the best one. Crucially, it proposes only. Nothing changes until you accept, and the proposed plan is clamped never worse than the standard sort. A short milling job that should feed a downstream machine early, but that the priority sort buried behind a long job, is exactly the kind of gain the optimizer surfaces. The optimizer guide covers this, and a worked case appears in why schedule stability can beat schedule optimality.

Reading a sequence like the engine wrote it

When a job lands earlier or later than you expected, walk the keys in order:

1. Did a higher-priority job claim the slot? Lower priority number wins.
2. Same priority? The earlier start date wins, then the earlier due date.
3. Is this a make-to-stock producer? It sorts ahead of its consumers in the same run.
4. Was the optimizer accepted? Then the sequence came from an approved proposal, not the standard sort.

Nine surprises out of ten resolve at the first two checks. The sort is simple on purpose: a planner can predict it, reproduce it, and explain it. The direction of scheduling within that sequence, forward or backward, is a separate decision covered in push vs pull scheduling, and the full engine pipeline lives in the scheduling engine guide. See how the sequence forms on your own orders in EDGEBIC.