Optimizer Goals in EDGEBIC: Four Presets, One Guarantee

An optimizer goal in EDGEBIC by User Solutions is not a single number to minimize. It is an ordered list of measures, compared tier by tier, so the goal you pick decides what the optimizer is willing to sacrifice. Four presets ship, all four carry the same never-worse guarantee, and picking between them takes about ten seconds once you know what each one ranks.

This post is about the goals themselves. For the run-and-read workflow, see how to run and read an optimization. For the whole feature, the optimizer guide is the pillar.

Why Ordered Tiers Instead of One Score

The obvious way to score a schedule is to blend measures into one number: some hours of lateness, some hours of makespan, some hours of disruption, all multiplied by weights and added up. It is also the way to build a scoring function nobody can reason about, because the weights silently trade things you never meant to trade.

EDGEBIC ranks lexicographically instead. Each goal is a list of measures in priority order, and comparing two candidate schedules works like comparing two words in a dictionary: the first tier where they differ by more than a small tolerance decides it, and the rest are consulted only on a genuine tie.

The practical consequence is honesty about trades. Under On-time first, a candidate that removes one late job wins even if it lengthens the overall plan, because due dates sit above makespan in that preset. That is a decision you made when you picked the goal, not a decision a weight made for you. Tier boundaries are real boundaries here, never simulated by making one weight enormous.

The Four Presets and What They Rank

On-time first

The default, and the right choice most days. It protects delivery promises above everything else: the optimizer does what it can to finish every job by its due date, even when that means the plant as a whole finishes a little later.

Note the second tier. Weighted tardiness comes first, then the count of late jobs. Those two measure different things and can disagree: a plan that turns one job three weeks late into three jobs one day late reduces the count and increases nothing else, whereas a plan that shaves two hours off a badly late job improves weighted tardiness without changing the count. Ranking them in that order says lateness hours matter first, and how many customers are affected matters second.

Fastest overall finish

This one compresses the plan end to end, so the plant frees up sooner. The trade is explicit: an individual job may finish later than it would have, if that shortens the overall plan. Use it when you are working through a backlog, or when the question is "when can we take new work", not "will this customer get their parts Friday".

Least setup time

Groups similar work so machines spend less of the shift changing over and more of it producing. In a paint shop or a plastics cell, that is often the single largest recoverable loss on the floor, which is the same argument behind changeover time reduction.

This goal is data-gated: it stays hidden until sequence-dependent setup data exists, because ranking candidates by changeover hours is meaningless without a matrix that says what each changeover costs. Populate the setup matrix and the goal appears automatically. Selecting the mathematical solver makes it stronger still, because with an eligible matrix the solver treats changeovers as part of the sequence it is choosing rather than as a fixed cost per operation.

Fewest changes

Improves the plan while disturbing the floor as little as possible, moving an operation only when the gain clearly justifies the disruption. This is the goal most planners underuse.

Schedule nervousness is a genuine cost, not a comfort preference. When Monday's printed plan is replaced by a different plan on Tuesday afternoon, supervisors stop reading the printed plan, and a mathematically better schedule that nobody follows is worse than a slightly weaker one the floor actually runs. Fewest changes is how you take improvements without paying that cost.

What the Measures Actually Mean

Every goal reads the same numbers, computed once by the same calculator that fills the comparison screen and the audit record. There is no second, private math behind the ranking, which matters when somebody asks whether the numbers in the audit trail are the numbers the optimizer used.

Two of these deserve a note.

Weighted tardiness distinguishes a job two hours late from one two weeks late, which a simple count cannot. It also respects priority, so a high-priority job's lateness dominates a low-priority job's. That combination is why it sits at the top of the default preset rather than the late count.

Plan changes measures nervousness against the plan the floor already knows, comparing matched operations and ignoring movements smaller than about a minute. That reference point matters, and it leads directly to the next section.

The Stability Guard: A Detail With Consequences

Measuring nervousness only makes sense when there is a committed plan to be nervous about. On a first schedule, there is none, and scoring disruption against a plan nobody has ever seen is noise.

So when no committed plan exists, stability tiers are stripped from the goal for that run. This is not cosmetic. A meaningless tier that never quite ties would deaden every tier ranked below it, so the optimizer would appear to ignore makespan entirely. If stripping empties a preset completely, which happens when you run Fewest changes on a first schedule, the goal falls back to the on-time tiers so you still get a sensible answer rather than an arbitrary one.

The practical takeaway: Fewest changes is a mid-week tool. On a fresh schedule, it has nothing to be stable relative to.

Ties, Tolerances, and Why They Matter

Tier comparisons use a small tolerance rather than exact equality, and the reason is practical. Two schedules whose weighted lateness differs by a hundredth of an hour are, for planning purposes, the same schedule. Treating that as a difference would let a meaningless rounding decide the winner and stop the comparison before it ever reached the tiers you care about.

So a genuine tie on the top tier passes the decision down to the next one, and only a difference large enough to matter stops it. That behavior is what makes the lower tiers useful instead of decorative: under On-time first, two candidates that both achieve zero lateness are then separated by stability, and if they tie there too, by makespan. The goal is a ranked conversation, not a single question.

Picking a Goal in Practice

A simple weekly rhythm covers most shops:

1. Monday, planning the week: On-time first. The plan is still yours to shape, and due dates are the point.
2. Mid-week, after the floor has committed: Fewest changes. Take the improvements that are clearly worth the disruption and leave the rest.
3. Backlog clearing or a capacity question: Fastest overall finish, then read the new plan end date.
4. A changeover-heavy cell with matrix data: Least setup time, ideally with the mathematical solver selected.

Trying a goal costs nothing. Every goal carries the same guarantee, so you can run, look, and discard as often as you like: the proposal lives on the screen until you accept it, and nothing is written before that. As the in-app goals guide puts it, every goal is guaranteed never to make your plan worse than it is today.

That guarantee has a precise meaning worth understanding rather than assuming, and it is covered in locked jobs and the never-worse guarantee.

Why a Proposal Can Show a Row Getting Worse

This is the most common question the comparison screen produces, and the goal structure is the answer.

Suppose On-time first proposes a plan where late jobs drop from 1 to 0 and makespan rises from 18 hours to 19. The optimizer calls this better and it is right: weighted tardiness and the late count sit above makespan in that preset, so the improvement on the tiers you asked for outranks the loss on a tier you ranked lower. The change column spells the direction out in words on every row, so nothing is hidden.

If the trade offends you, that is useful information about your goal choice rather than about the optimizer. Discard, switch to Fastest overall finish, and run again. The ranking reverses and so does the trade.

Two Layers, Same Goals

The goals are identical whichever engine you run. The default multi-run search evaluates many complete alternative schedules produced by the real scheduling engine and returns the best one it found under your goal, guaranteed never worse than your current plan. The mathematical solver additionally computes how good any schedule could possibly be under that goal, so it can report a proven optimality gap.

Same goal list, same measures, same guarantee. Only the badge language changes, and the meaning of that badge is explained in what an optimality gap is.

Adding to the List

The preset list is deliberately short. Four goals covering due dates, throughput, changeover, and stability spans nearly every planning conversation a shop actually has, and a dropdown with fifteen entries mostly produces guesswork.

If your operation genuinely optimizes against something else, that is a conversation worth having with a real workload in front of you: goals in EDGEBIC are registry entries with their own measures and documentation rather than hard-coded branches, so the list is extensible by design.

Where to Go Next

Run one and read it: how to run and read an optimization covers the workflow end to end. If a run comes back with no improvement, why the optimizer returned the same schedule explains why that is often the correct answer. The habits that waste optimizer runs are collected in optimizer usage mistakes. For where optimization sits among everything else EDGEBIC does, start at the complete guide, and for the general discipline, production schedule optimization is the foundation post.