Anomaly Checks Show Nothing When I Filter to One Job: Causes and Fixes

When the inventory or setup matrix checks return no rows on a job-filtered anomaly run, nothing is wrong with the report: those checks are plant-wide and only produce rows on a full scan. EDGEBIC by User Solutions runs more than forty structural checks after a scheduling run, and they do not all share a scope. Some are job-shaped, some audit master data across the whole plant, and one group audits routing configuration that has no job attached at all.

Reading the scope wrong is the most common way a planner gets a false sense of a clean plant. This post explains which checks live at which scope, why a chip can read zero without having run, and the two-pass habit that closes the gap. It is the scope entry in the EDGEBIC troubleshooting guide. For the report itself, how to run the scheduler anomalies report covers the screen step by step, and what is a scheduling anomaly check covers the concept.

What You Are Seeing

You open the anomaly report, type a job number to narrow the scan, and the result looks reassuring. The chip strip is mostly quiet. The inventory chips read zero. The setup matrix chips read zero. The routing-configuration chips read zero. Then a plant-wide scan run later that day, or a problem on the floor, shows that one of those checks had rows all along.

Why It Happens

Cause 1: The Check Is Plant-Wide and the Filter Excluded It

The job filter narrows the scan to schedules whose job number matches what you typed. That works for anything measured against a schedule. It cannot work for a check whose subject is a product record, a ledger balance, or a matrix cell, because those objects do not belong to a job.

The inventory series and the setup matrix series are both in that category. They run only when the scan has no job filter. On a filtered run they are skipped, and skipped is not the same as passed.

How to tell: you ran the report with a job number in the filter and the inventory or matrix chips are all quiet.

Cause 2: The Chip Strip Always Shows Every Check

The summary strip is built from the full catalog, so every check gets a chip on every run regardless of scope or result. A chip with no rows renders the same way whether the check ran and found nothing or never ran at all. The strip is a catalog view, not a proof of execution.

How to tell: the chip is present and quiet, but the check belongs to a plant-wide series.

Cause 3: The Check Audits a Routing, Not a Schedule

A third group evaluates routing configuration: the overlap gates, the transit mode, and the fields the scheduler does not read. These fire on the routing record itself, which is why they can flag a problem immediately after you save a routing change and before you have scheduled anything. A job filter suppresses them for the same reason it suppresses the inventory series: their subject is not a schedule.

How to tell: you saw routing warnings on a full scan and they vanished when you narrowed to a job.

A Related Case: the Check Ran and Genuinely Passed

If the check is job-shaped, over-utilization, instance collisions, idle gaps, dependency violations, off-calendar bookings, plan inversion, configuration gaps, lost hours, or consistency drift, then zero rows on a filtered run is a real pass for that job. Those are the checks a job filter is built for.

How to Fix It

• For a master-data audit, clear the filter. Run the report with no job number so the inventory and setup matrix checks evaluate. This is the only scope that produces their rows.
• For a routing-configuration audit, clear the filter too. The overlap, transit, and dead-field checks need the unfiltered scan.
• For a single job, keep the filter. It is the fastest way to triage one job's schedule without reading the whole plant.
• Treat a quiet chip as a question, not an answer, until you know which scope you ran.

How to Diagnose It, in Order

1. Look at what you typed in the filter. A job number in the box means plant-wide checks were skipped.
2. Identify the series of the check you care about. Schedule-shaped checks filter; inventory, matrix, and routing-configuration checks do not.
3. Re-run with no filter and compare the chip strip against the filtered run. Any chip that lights up now was suppressed before.
4. Sort the new rows by severity and work the critical ones first, as in clearing scheduler anomalies before publishing.
5. Re-run the report after any fix, because it reads current stored state rather than the state at the time of the run you were looking at.

How to Prevent It

• Make the audit two passes. Filter to the job when you are chasing one job's schedule, then clear the filter for the plant-wide pass. The second pass is the one that catches inventory drift and matrix rot.
• Run the plant-wide scan on a schedule you keep, for example before every published plan and after every master-data import. A freshly imported setup matrix is exactly the case that needs an unfiltered scan.
• Audit routing configuration right after you save a routing, not after the next scheduling run. Those checks do not wait for the engine.
• Read severity before scope. A critical row on a filtered run still deserves attention first, and the anomaly report flags a job I think is fine covers the findings that are usually acceptable.