Skip to content

Predicted By Troubleshooting

Common problems when creating and running a Predicted By check, their causes, and how to resolve them.

Validation Fails When Creating the Check

Clicking Validate returns an error instead of a success message.

Cause: The rule could not run against the selected data. The most common reasons are an invalid Expression, a Tolerance that is missing or not a number, an invalid Filter Clause, or a container that failed to load.

Resolution:

  1. Review the error message: it explains what needs attention.
  2. Check the Filter Clause for typos: it must be a valid SQL WHERE expression for the selected container.
  3. If the message says the container is marked as Unloadable, the container was skipped after repeated operation failures. Follow the steps in Unloadable Container Error.

Almost Every Row Is Reported

The check fires on nearly the whole container.

Cause: Usually the tolerance is far tighter than the column's real drift, or the expression predicts on a different scale than the field (a fraction against an amount, for example).

Resolution: Compare a few predicted values against the actual ones to confirm the two are on the same scale, then set the tolerance just outside the drift you observe.

Rows With NULL Values Are Not Flagged

Records where the field or the expression's result is NULL never appear as anomalies.

Cause: When the expression returns NULL or the field is NULL, the comparison has nothing to measure and the row passes.

Resolution: Add a Not Null check on the field and on each column the expression depends on.

The Tolerance Fits Small Values but Not Large Ones

The check is quiet on part of the data and noisy on the rest.

Cause: The tolerance is an absolute number and does not scale with the size of the prediction.

Resolution: Scope the check to a comparable slice with a filter, or express a relative comparison with Satisfies Expression.

Validation Fails on a Date or Timestamp Field

Clicking Validate on a check whose field is a date or timestamp returns a data type error.

Cause: The Expression can transform only the predicted value. The selected field stays a date or timestamp, so the difference between the two is not a number the tolerance can measure.

Resolution: Write the complete comparison in a Satisfies Expression check instead, converting both sides to the same numeric unit (for example, abs(unix_timestamp(l_receiptdate) - unix_timestamp(date_add(l_shipdate, 15))) <= 86400).

Validation Fails on the Expression

Clicking Validate returns an error instead of a success message.

Cause: The expression is not valid SQL for this container: a misspelled column, an unbalanced parenthesis, or a function the source does not provide.

Resolution: Read the error message, then check the column names against the container and simplify the expression until it validates.

An Edited Check Keeps Behaving the Old Way

You changed the configuration but the anomaly list did not change.

Cause: Edits take effect on the next Scan. Saving the check does not re-evaluate the data, and anomalies raised under the previous configuration are not modified.

Resolution: Run a Scan on the container (or wait for the scheduled one). Old anomalies stay open until you triage them or a Full scan with Auto Resolve clears them. See What Happens to Existing Anomalies.

No Anomalies Although the Data Looks Wrong

A Scan ran, the data clearly breaks the rule, but nothing was reported.

Cause: One of these configurations is excluding the violations:

  • The check is in Draft status: Draft checks are not evaluated by Scans.
  • The Filter Clause excludes those rows before the evaluation runs.
  • Coverage is below 100% and the failing fraction stayed within the tolerance, so the check passed.

Resolution: Confirm the check is Active and test the filter expression against the offending rows. Then review the coverage setting; see Coverage and Tolerance.

Expected One Anomaly per Row, Got a Single Rolled-Up One

Many rows failed, but the scan reported one Shape Anomaly instead of per-row Record Anomalies.

Cause: When the number of failing rows exceeds the scan's rollup threshold, the per-row findings are grouped into one rolled-up Shape Anomaly.

Resolution: This is expected behavior; the rolled-up anomaly carries sampled source records. To change the threshold, see Maximum Record Anomalies per Check.