My Optimizer Proposal Disappeared Before I Could Accept It

An optimizer proposal in EDGEBIC by User Solutions lives only on the Optimizer screen until you press Accept, so closing the application discards it and nobody else can see it. That is the entire cause, and it is the flip side of the guarantee printed on the screen's safety strip: nothing is saved until you decide, which is exactly why nothing survives if you do not.

Nothing was lost in any meaningful sense. The database is byte for byte as it was, your current plan is intact, and the only cost is the seconds the solve took. But the proposal cannot be retrieved, only recomputed, and that changes how you should schedule the human part of the decision.

This is one symptom in the EDGEBIC troubleshooting guide family. If your proposal is still on screen and Accept is refusing it, that is a different fault, covered in the optimizer refused my proposal as stale.

What You Are Seeing

One of these three:

• You ran the optimizer, left the proposal open, closed the application or restarted the machine, and came back to an empty Optimizer tab.
• You told a colleague to look at the proposal on their own machine and they see nothing.
• You ran it, went to a meeting, came back, and the session had ended in between.

In every case there is no error, no warning, and no record of the run anywhere.

Why It Happens

A Proposal Is a Screen Object, Not a Saved One

The optimizer computes entirely in memory and holds the result on your screen. Until you press Accept, the database and everyone else's view of it are untouched. That is a deliberate design choice with two consequences, one of which everyone likes and one of which surprises people.

The consequence everyone likes: running the optimizer cannot disturb the live schedule or another planner's work, so you can press the button on a Tuesday afternoon without any risk assessment.

The consequence that surprises: a proposal has no existence outside the session that produced it. It does not survive a restart, it is not stored for later, and it is not shared with another user or another machine.

How to tell: there is no error and no partial state. The tab is simply back to where it was before you ran.

Only Accept Writes Anything

Accept is the moment the proposal becomes real. It saves through the same pipeline as a normal scheduling run, with the same protections for recorded work, every schedule view refreshes, and one audit record is written capturing the plain-language explanation, the goal you chose, the numbers before and after, and the list of moves. That record is retrievable months later from the job audit trail.

Discard does the opposite and leaves the database untouched. Closing the application is a Discard you did not mean to make.

The Fix

There is nothing to repair, so the fix is a working practice rather than a setting.

Run and decide in one sitting. Pick your goal, pick your time budget, read the verdict, and Accept or Discard. Budgets are short by design, so this is a single-visit task rather than a background job you check on later.

If somebody else has to approve, take the evidence, not the proposal. Before you leave the screen, capture the three things that make the argument: the one-line verdict, the KPI comparison against the current plan, and the move list showing which operations shift and by how much. Those are what an approver actually reads. Then re-run and Accept once the answer is yes.

Re-running is cheap and repeatable. The search is seeded, so the same data and the same goal produce the same proposal. Re-running is not a gamble on getting a different answer; it is recomputing the answer you already saw.

If the numbers move on the re-run, the plant moved. A colleague rescheduled, actuals arrived from the floor, or an order changed. That is the same condition the "changes arrived while you reviewed" banner catches mid-review, and the right response is to accept the fresh answer rather than chase the stale one.

What Is Actually Guaranteed

It is worth being precise about the promises, because they are what make a lost proposal a non-event.

The multi-run search returns the best complete schedule it tried and is guaranteed never worse than the baseline. The mathematical solver additionally reports how close its answer is to the best theoretically possible, so it can state a proven optimality gap. Neither engine promises the perfect schedule, and neither one saves anything without you.

Preventing the Next One

Treat the optimizer as a decision meeting, not a batch job. Ten to sixty seconds of solve time is short enough to run live in front of whoever needs to agree.

Do not use the open tab as your record. The audit record written at Accept is the durable one. If you want a record of a proposal you decided against, capture it before you Discard.

Know which engine you are on. The badge language differs, and so does what you can claim in the meeting. Running and reading an optimization covers the screen, and optimizer goals and presets covers choosing the goal that makes the proposal worth accepting in the first place.