The Optimizer Explain Dialog and Audit Trail

The Explain dialog tells the plain-language story of an optimization run, and Accept saves that exact story to the audit log, so the dialog you read and the record kept months later are literally the same. The dialog turns a wall of numbers into a narrative: what you asked for, how the search went, what changed, and which guarantees held. When you Accept, that identical narrative is serialized into one audit row alongside the goal, the seed, the solve statistics, and both sets of measures. There is no second summary written later that could drift. The result is transparency at the moment of decision and a faithful record of it forever after.

EDGEBIC by User Solutions builds the explanation once per run and reuses it for both surfaces. This post walks through the five sections of the dialog and how they land in the audit trail. For the numeric side of a result, see how the optimizer scores a schedule, and for the moment of commitment, what happens when you accept an optimized schedule.

The five sections of the dialog

The Explain dialog opens on a result and lays the run out in order:

Read top to bottom, it answers the questions a planner actually has. What was I optimizing for. How hard did it look. What did it achieve. What specifically moved. What did it protect. A verdict badge and a KPI table give you the headline, but the dialog gives you the reasoning, and it does so in language you could paste into an email.

The Outcome section and the honest certificate line

The Outcome section is where the honesty guardrails show. It lists each measure before and after, then a certificate line that states plainly what the run can claim. For the default multi-run engine, that line reflects a heuristic search: the best of several complete schedules tried, guaranteed never worse than your plan, with no claim of proven optimality. For the mathematical solver, the line can state a proven optimality gap, or that no better plan exists at all when the gap is zero. The dialog never overstates. If nothing beat your plan, the Outcome says so and reports how close the nearest challenger came, which tells you the search was thorough rather than empty.

The locked-jobs section on the solver engine

When you run the mathematical solver, the dialog carries one more piece: the list of jobs it left alone and why. Each locked job appears with its reason, such as a multi-instance work center or lot streaming, so you can see exactly which parts of your plan the solver did not rearrange and understand that it did so for safety. This is the same honesty visible in the diagnostics, brought to the front for the planner. For the mechanism, see how the optimizer locks features it does not model.

From dialog to audit, unchanged

The link between the dialog and the audit is the important part. The optimization service constructs the explanation record once, when it prepares the proposal. That record populates the Explain dialog you read. When you Accept, the service serializes the same record into one audit row in the schedule change log, marked as an optimizer application. The row's payload carries the full explanation, the goal key, the seed, the solve statistics, and both KPI sets.

Because the audit row is built from the same record the dialog showed, there is no possibility of drift between what a planner saw at decision time and what the log preserves. A summary written separately later could quietly differ from the screen. This one cannot, because there is no separate summary. The dialog and the audit are two views of a single artifact.

Why the matching record matters

Months after an acceptance, someone asks why the plan looks the way it does, or an auditor wants to know what a scheduling change did. You query the schedule change log for optimizer application records and read the row. It tells you the goal that was chosen, how the search ran including the seed that makes it reproducible, every measure before and after, the significant moves in plain sentences, and, on the solver engine, which jobs were locked. That is a complete, faithful account of the decision, not a reconstruction. You are reading the same story the planner read when they clicked Accept.

The seed in that record is not decoration. Because the search is deterministic, the same inputs with the same seed reproduce the same plan, which lets a support case or a review rerun the exact optimization. See determinism and reproducibility.

Discard leaves no audit row

The audit trail records decisions, not experiments. If you Discard a proposal, nothing is written to the schedule change log, because nothing changed in the plan. The database is byte-identical to before the run. Only an Accept, an actual change to your committed schedule, produces an audit row. This keeps the log clean: every optimizer record in it corresponds to a real change a planner chose to make, each with its full story attached.

The bottom line

The Explain dialog narrates a run in five sections, Goal, Search, Outcome, Changes, and Protections, plus locked-job reasons on the solver engine, with an honest certificate line that never overstates. Accept serializes that exact record into one audit row, so the dialog and the months-later log tell the same story, seed included for reproducibility. Discard writes nothing. To read a run's story, open the Explain dialog on a result in the Optimizer tab; to audit an accepted one, query the schedule change log. For the wider picture, read the EDGEBIC optimizer guide, and start at EDGEBIC.