Expected Values Anomaly Reporting
How the Expected Values check reports violations: the anomaly messages it produces, what the numbers mean, how the offending value appears in Source Records, and how to replace the default message with a value from your own data.
Anomaly Messages
On a scalar field at 100% coverage, Expected Values reports violating rows as Record Anomalies. Below 100% coverage, a failed coverage assertion produces one Shape Anomaly for the dataset. On an Array field the rule runs element-wise as a field-level check, which always reports a Shape Anomaly (see Array Fields). The two templates are:
Record Anomaly
Shape Anomaly
What the Numbers Mean
- X.XXX%: the fraction of evaluated rows that failed the comparison.
- N: the number of rows evaluated (after the filter, if any).
- K: the number of rows whose value was non-NULL and not in the list.
When a filter is set, both Record and Shape Anomaly messages end with [filter: <expression>].
Scan settings can group a large number of Record Anomalies into one rolled-up Shape Anomaly. This behavior applies across rule types and is documented under Maximum Record Anomalies per Check.
Source Records Behavior
When you open the source records for an Expected Values anomaly, the platform highlights only the offending cell for the field the check applies to. Other columns in the same row are rendered normally. This matches how the check semantics work: the violation is about a single field's value, not the entire row.
The Sample Data tables on the Examples page follow the same convention: one row per source record, with only the failing cell visually marked.
Custom Anomaly Description
Expected Values supports Custom Anomaly Description because it emits Record Anomalies. When anomaly_message_field (or the Custom Anomaly Description toggle in the UI) points at another column on the same row, the Record Anomaly message becomes the value of that column. When the referenced column is null, missing, or empty, the standard template is used instead.
Because the option only applies to Record Anomalies, it does not affect Shape Anomalies, which always use the fixed template.
See Also
-
How It Works
The complete reference: definition, field scope, properties, matching rules, arrays, filter behavior, and coverage.
-
Examples
Three production scenarios with sample data, anomaly messages, and the SQL equivalent of what the check evaluates.
-
Best Practices
Guidelines for sizing the vocabulary, matching exactly, pairing rules, and keeping the signal clean.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.