Equal To Check FAQ

Answers to common questions about how the Equal To check pins a numeric field to a constant, how tolerance works, and how anomalies are reported, grouped by topic.

Behavior

What happens when I select several fields?

They are asserted together: a row passes only when every selected field equals the value, and fails as soon as one does not. The message names the field that failed.

Why does an exact equality fail on values that look right?

Computed numbers can differ far below the printed precision. Set the Numeric comparator with a margin that matches the arithmetic.

What does the Numeric comparator do?

It adds a tolerance before the comparison, absolute or as a percentage of the compared value, so a near-miss inside the margin still passes.

How are NULL values treated?

NULLs fail by default: each selected field must be present and equal to the value, so an empty field is reported like a wrong one. Setting a Numeric comparator reverses this for rows whose selected fields are all NULL, which then pass; a row where only some of them are NULL still fails. Add a filter such as <field> IS NOT NULL when the missing values are expected and should not be reported by this check.

Can I pin a text or date value?

Not with this rule: the field picker lists numeric fields only. Use Expected Values with a single-entry list instead.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: The field '<field_name>' is not equal to the expected value of <value>

Shape Anomaly: For the field '<field_name>', X.XXX% of N records (K) are not equal to the value of <value>

When a filter is set, both messages end with [filter: <expression>].

Does Equal To produce Record Anomalies, Shape Anomalies, or both?

At 100% coverage (the default), violating rows are reported as Record Anomalies. Below 100% coverage, a failed coverage assertion produces one Shape Anomaly for the dataset. A scan can also roll up a large number of Record Anomalies into one Shape Anomaly.

Does Custom Anomaly Description work for Equal To?

Yes. Equal To emits Record Anomalies, so the anomaly_message_field payload field (and the Custom Anomaly Description toggle in the UI) replaces the Record Anomaly message with the value of the named column on the violating row. When that column is null, missing, or empty, the standard Record template is used instead. The Shape Anomaly always uses the fixed template.

Configuration

Can I lower the coverage on an Equal To 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 change the expected value later?

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

What permission do I need to create or edit an Equal To 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.

Should I use Equal To or Equal To Field?

Use Equal To when the reference is a constant. Use Equal To Field when it is another column on the same row, which keeps the rule correct as the data changes.