Why Optimizer Changes Show an Arrow and a Word

Every Change cell in the optimizer comparison carries a direction arrow and the word better or worse, never a color alone, so the meaning survives printing, photographing, projecting and color vision deficiency. In EDGEBIC by User Solutions the comparison table lists Measure, Current, Proposed and Change, and that last column always spells the direction out. It is a small decision that makes the table readable in a shift meeting rather than only on the planner's monitor.

What the table shows

Four columns, one row per metric. The Change cell is the one doing the interpretive work: rather than leaving you to compare two numbers and infer a direction, it states the direction and labels it as an improvement or a regression. A row with no movement says so explicitly with a dash and the words no change, so an unchanged measure is never ambiguous with a missing one.

Why not just color the cell green or red

Because a production schedule comparison rarely stays on the screen it was rendered on. It gets:

• printed in black and white and pinned up
• photographed on a phone and sent to a supervisor
• pasted into an email that strips styling
• projected in a room where the projector washes out reds
• read by someone with color vision deficiency, which affects a meaningful share of any workforce

In all five, a color-only signal loses its meaning entirely, and the reader is left comparing two numbers under time pressure. An arrow plus a word survives every one of them. Color coding can still be present as reinforcement, but it is never the only carrier of the message, which is the accessibility principle worth applying to any status indicator you build elsewhere.

Which rows you get, and when

A shorter table than you expected is usually a condition rather than a fault.

So if you are hunting for a setup number and cannot find the row, the answer is that no setup matrix is configured yet, which is the same condition that hides the Least setup time goal from the dropdown. If the plan-changes row is missing, there is no committed plan yet for the proposal to be measured against.

Reading it in thirty seconds

The order matters more than the speed:

1. Find the row that matches your goal. That is the measure you asked the optimizer to protect, and it is the one that has to point the right way.
2. Scan for any cell marked worse. Decide whether you accept the trade.
3. Read the move list. It lists only operations that actually move, so its length is your disruption estimate at a glance.
4. Accept or Discard.

Reading rows in the order they appear rather than starting with your goal's row is the usual reason this takes several minutes instead of thirty seconds.

Why a worse row can be correct

Goals are ranked rather than balanced, so the optimizer will trade a small loss on a lower-priority measure for a larger gain on the one you chose. Removing a late job at the cost of half an hour of makespan is a good trade under On-time first and a poor one under Fastest overall finish. The table shows you both sides instead of hiding the cost, which is what makes it trustworthy. Why an optimized plan can look worse on one measure works through that trade in detail, and how the optimizer ranks goals in strict order explains the ordering behind it.

Two things bound how bad a trade can be. The proposal is clamped so it can never be worse than your current plan overall on the goal you chose, and nothing is written until you press Accept. So an offensive trade costs you a Discard, not a recovery.

Taking the comparison to other people

The table travels well on paper because of the arrow and word convention, but the reasoning does not. For that, use Explain and then Copy, which puts the whole plain-language account on the clipboard: the goal you asked for, how the search went, each measure before and after, the significant moves as sentences, and what was protected.

The reason to prefer that over a screenshot is continuity. The text Explain shows is the same text stored in the audit record when you accept, so the conversation today and the audit trail months later quote one story rather than two. The optimizer explain dialog and audit trail covers the mechanism.

A habit worth copying elsewhere

If you build or specify internal reporting around your schedule, the convention here is worth reusing: never let color be the only thing carrying a direction. Spell the direction out, keep both the before and after numbers visible, and say no change explicitly rather than leaving a blank. Those three rules are why this particular table can be read on a printout in a noisy room by someone who has thirty seconds, which is the actual environment most scheduling decisions get made in.

The takeaway

The optimizer writes an arrow and the word better or worse into every Change cell because color alone would not survive a printout, a phone photo, a projector or color vision deficiency. Expect Late jobs, weighted lateness and makespan on every run, a Setup row only when setup data exists, and a plan-changes row only when a committed plan exists. Read your goal's row first, scan for trades, then read the changes-only move list, and use Explain and Copy when the reasoning needs to travel. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with reading the optimizer move list and how the optimizer scores a schedule.