Contains Email Check FAQ

Answers to common questions about how the Contains Email check matches values, how it handles NULLs and arrays, and how anomalies are reported, grouped by topic.

Behavior

Does the whole value have to be the expected value?

No. The check tests for containment: the row passes as soon as an email address appears anywhere inside the value. When the field must hold nothing else, use Matches Pattern with an anchored expression.

How are NULL values treated?

NULLs pass. A row with NULL in the evaluated field is not counted as a violation. An empty string, on the other hand, is a present value with no match and is reported. If the field must be populated, pair the check with a Not Null check.

What happens on an array field?

Every element is tested and the row fails as soon as one element does not contain the pattern. NULL arrays and empty arrays pass, and NULL elements inside an array are skipped. The evaluation runs as a field-level check, so it reports a Shape Anomaly for the field rather than per-row Record Anomalies, whatever the coverage is set to.

Does the filter run before or after the evaluation?

Before. The platform applies the filter first and then evaluates only the rows that pass the filter. Filtered-out rows cannot trigger an anomaly and are not counted in the totals.

Does the check validate that the mailbox exists?

No. The check looks for the shape of an address in the text. It cannot tell whether the domain resolves or the mailbox accepts mail; that requires a delivery attempt outside the platform.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: <field> has the value <value>, which does not contain an email address

Shape Anomaly: <field> values do not contain an email address, affecting N of M asserted records

When a filter is set, the message names it at the end of its first sentence, as (applied to records where <expression>). Record and Shape Anomaly messages both carry it.

Does Contains Email produce Record Anomalies, Shape Anomalies, or both?

On a scalar field at 100% coverage (the default), violating rows are reported as Record Anomalies, and below 100% coverage a failed coverage assertion produces one Shape Anomaly for the dataset. On an array field the rule is evaluated element-wise as a field-level check, which always reports a Shape Anomaly.

Scan settings can group a large number of Record Anomalies into one rolled-up Shape Anomaly, which carries the Shape Anomaly message. This behavior applies across rule types and is documented under Maximum Record Anomalies per Check.

Does Custom Anomaly Description work for Contains Email?

On a scalar field, yes. Contains Email emits Record Anomalies there, so the anomaly_message_field payload field (and the Custom Anomaly Description toggle in the UI) applies. It has no effect on an array field, which reports a Shape Anomaly.

When the option points at another column on the same row, the Record Anomaly message becomes that column's value for the violating row, shown as written. When the column is null, missing, or empty, the message falls back to the rule's standard wording, and when the column is masked the message reads <masked>. Shape Anomaly messages are unaffected.

Configuration

Can I lower the coverage on a Contains Email check?

Yes. Coverage at 1.0 (100%) means every row must pass. Lowering coverage to 0.995 allows up to 0.5% of rows to fail without raising an anomaly; once the failing fraction goes past that, the check reports a Shape Anomaly. Use lower coverage with care: a real regression that happens to fall just under the threshold will not raise an alert at all.

Can I point the check at a different field later?

Yes. In the UI, open the check, change the Field, and click Update; see Edit a Check for the full steps. Through the API, a PUT to /api/quality-checks/{id} updates fields. The rule type, the target container, and the associated Check Template stay immutable; see the API page for the editable/immutable matrix.

What permission do I need to create or edit a Contains Email check?

The Drafter team permission on the datastore covers Draft work (creating a check as Draft or editing it while it stays Draft). Anything that puts the check into evaluation, such as creating or editing an Active check, archiving, or deleting, requires the Author team permission (or above). Viewing only requires Reporter. See Permissions for the full matrix.