The Optimizer Refused My Proposal as Stale: Causes and Fixes

When Accept on an optimizer proposal is refused as stale, it means the schedule changed after the proposal was generated, and the optimizer will not overwrite the newer state with a plan measured against an out-of-date baseline. EDGEBIC by User Solutions never writes an optimized plan to the live schedule on its own: it produces a proposal you review and then Accept or Discard, and the staleness guard is what keeps that deferred-apply step honest.

This post covers the refused-accept symptom in the EDGEBIC troubleshooting guide. It is a different situation from the optimizer made my schedule worse, which is about the result, and from why the optimizer returned the same schedule, which is about no change at all. For how the optimizer weighs its goals before it proposes anything, see how the optimizer ranks goals in strict order.

What You Are Seeing

You generated an optimizer proposal, reviewed the deltas, and clicked Accept, but instead of applying, the plan reports the proposal is stale and declines to commit it. The proposal looked fine; the refusal comes at the moment of acceptance, not at generation.

Why It Happens

Cause 1: A Reschedule Ran After the Proposal Was Built

The optimizer measures its candidate against a baseline captured when the run started. If a full or targeted reschedule ran between generating the proposal and accepting it, the live plan no longer matches that baseline. Accepting the older candidate could undo the reschedule, so the accept is refused.

How to tell: a scheduling run happened, by you or anyone, after you generated the proposal.

Cause 2: Actuals Were Logged in Between

Logging actuals moves the schedule forward from the position the proposal assumed. Because completed and in-progress work is never overwritten, a proposal built before those actuals landed is out of date the moment they are saved.

How to tell: shop-floor hours or a completion were recorded after the proposal was generated.

Cause 3: Another Proposal Was Accepted First

If a second proposal (yours or another planner's) was accepted between your generate and your accept, the schedule already moved to that plan. Your proposal is now measured against a state that no longer exists.

How to tell: the plan changed to a different optimized result before your accept.

How to Fix It

• Re-run the optimizer. A fresh proposal is built against the current schedule, so its baseline matches reality and Accept commits cleanly.
• Review and accept promptly. The guard only fires when the base moves between generating and accepting, so a tight generate-then-decide loop avoids it. A proposal also lives only on your screen until you Accept, which is why an optimizer proposal can disappear before you accept it.
• Make other changes first, then optimize. If you need to log actuals or reschedule, do that, then generate the proposal so it starts from the current state.
• Coordinate on shared plants. When more than one planner can change the schedule, let one drive optimization at a time so proposals are not invalidated underneath each other.

How to Diagnose It, in Order

1. Confirm a change happened after you generated the proposal: a reschedule, a batch of actuals, or another accepted proposal.
2. Discard the stale proposal. It is measured against a state that no longer exists and cannot be salvaged.
3. Re-run the optimizer so the new proposal starts from the current schedule.
4. Review the fresh deltas and Accept before making other changes.
5. If it keeps recurring, check whether a second planner or an automated reschedule is moving the plan while you work.

How to Prevent It

• Treat proposals as short-lived. Generate, review, decide. The longer a proposal sits, the more likely the plan moved under it.
• Log actuals and reschedule before optimizing, not after, so the proposal is built on current reality.
• Serialize optimization on shared plants, so two people are not accepting proposals against each other.
• Trust the refusal. A stale accept being blocked is the deferred-apply contract protecting newer work, not a fault to work around. The same never-overwrite discipline that preserves completed work is covered in the business case for risk-free optimization.