Positive Check FAQ

Answers to common questions about how the Positive check evaluates a numeric field, how zero and NULLs behave, and how anomalies are reported, grouped by topic.

Behavior

Does zero pass?

No. Positive requires values strictly greater than zero, so 0 is flagged. When zero is legitimate, use Not Negative.

How are NULL values treated?

NULLs pass. A row with NULL in the evaluated field is not counted as a violation. Positive only asserts that present values satisfy the rule. If the field must also be populated, pair the check with a Not Null check on the same field.

Which field types can I check?

Numeric fields: integers and decimals. Arrays of numbers are also accepted, and the check evaluates every element. A number stored as text does not appear in the field picker; expose it with a numeric type first.

Does the filter run before or after the comparison?

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

What happens on an array field?

Every element is tested, and the row fails as soon as one element breaks the rule. Empty arrays and NULL arrays pass, since there is nothing to evaluate. 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.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: The field '<field_name>' has value <row_value>, which is not a positive number

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

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

Does Positive 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. A scan can also roll up a large number of Record Anomalies into one Shape Anomaly.

Does Custom Anomaly Description work for Positive?

On a scalar numeric field, yes. Positive emits Record Anomalies there, 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. It has no effect on an array field, which reports a Shape Anomaly, and Shape Anomalies always use the fixed template.

Configuration

Can I lower the coverage on Positive 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 Positive 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.