How the Anomaly Report Keeps a Bad Schedule Off the Floor

A scheduling anomaly report keeps a bad plan off the floor by flagging the broken rows before the plan is printed, so a planner resolves them at a desk instead of an operator discovering them at a machine. EDGEBIC by User Solutions runs a set of automated checks against every freshly generated schedule, each targeting a specific way a plan can go quietly wrong: an operation that ends before it starts, actual hours with nothing planned behind them, an impossible gap between sequential steps. The plan is only as trustworthy as its worst undetected row, and the report is what finds that row while it is still cheap to fix.

This post is about the quality-control outcome. It sits under the EDGEBIC results guide. For what each check inspects, see what the anomaly checks actually look for.

A Bad Plan Fails Silently

The dangerous scheduling error is not the obvious one. An obviously broken plan gets caught. The expensive error is the one that looks fine: a job with a date field inverted so the operation reads as ending before it began, an actual hour logged against a step the routing no longer contains, a six-day gap between two sequential operations that no queue or transit time explains.

None of those announce themselves. They print onto a clean-looking schedule, an operator works to them, and the failure surfaces hours or days later as a scrapped setup, a stalled line, or a customer call. By then the cost is committed. The plan was wrong the whole time, and nobody could see it because a bad row and a good row look identical on a printout.

What the Report Actually Checks

The anomaly report runs targeted checks and returns only the rows that fail them. Each fired check names the job and the reason, so a planner reviews exceptions rather than the entire plan. The families of check map to the specific ways reschedules and data entry go wrong:

A non-empty result is not a catastrophe. It is a short list of jobs to look at. The value is that the list is short and specific instead of "check everything, trust nothing." For the underlying idea, see what is a scheduling anomaly check.

Why the Timing Is the Whole Point

Every error has a cost that grows with how late you catch it. The anomaly report exists to catch errors at the earliest and therefore cheapest moment.

• At the planner's desk: the fix is a minute of review and a correction to the data.
• On the printed schedule: the fix is a reprint and a re-brief.
• At the machine: the fix is a scrapped setup, a confused operator, and lost hours.
• At the customer: the fix is a chargeback, an expedite, or a lost repeat order.

Reviewing the report before release collapses that entire escalation to the first line. This is the same firefighting-reduction logic behind how finite capacity scheduling reduces firefighting, applied to plan quality rather than capacity.

Where the Errors Come From

Most anomalies are not typos. They are the residue of rescheduling. When you reschedule a job that is half done, the engine has to preserve the completed operations, replan only the remaining hours, and cascade the rest. That is exactly where the subtle failures live: a completed step and its forward replan both surviving, a partial operation getting a stray duplicate entry, an actual date landing before its own start after a manual correction.

Because these appear during the routine morning reschedule rather than during setup, they are easy to miss precisely when you are moving fastest. Running the report after the reschedule is what turns "I hope the reschedule was clean" into "I checked, three jobs need a look." For how completed work is meant to survive a reschedule, see why actuals are immutable.

A Flag Is a Question, Not a Verdict

The report is deliberately conservative in one direction: it would rather ask about a job that turns out fine than stay silent about one that is broken. Some flags surface a configuration that is unusual but intentional, and the correct response is to confirm the intent and move on.

That design is the right one. A check that never produces a false question also misses real problems, and the cost of a missed real problem is far higher than the cost of confirming an intentional one. The point is that a human looked. When you decide a flagged job is correct, you have not defeated the report. You have used it. See the anomaly report flags a job I think is fine.

What the Anomaly Report Cannot Do

It cannot tell you the plan is a good plan. A schedule can pass every check and still be a poor sequence that leaves the bottleneck idle. The report catches broken rows, not weak strategy. Optimization and constraint protection are separate concerns.

It cannot fix the row for you. It points at the job and names the problem. A planner still decides whether to correct the data, confirm the intent, or investigate the routing. The report shortens the search, not the judgment.

It cannot catch what it does not check. The checks target known failure shapes learned from real installs. A brand-new way to break a plan is invisible until a check is written for it. This is a floor on quality, not a ceiling.

It cannot run itself into your workflow. Somebody has to review it after each reschedule. A report nobody opens protects nothing, which is why it belongs in the daily rhythm next to the reschedule that produces the errors.

Want to see what a run against your data flags? Bring a live schedule to a demo and we will run the anomaly report together and read the exceptions line by line.