Skip to content

Distinct Count Check FAQ

Answers to common questions about how the Distinct Count check measures cardinality, why the count is approximate, and how anomalies are reported, grouped by topic.

Behavior

Is the count exact?

No. The platform uses an approximate distinct-count algorithm so the check stays cheap on large containers. On a small, controlled column the result is exact in practice; on a high-cardinality column expect a small margin of error.

Which operators are available?

Less Than, Less Than Or Equal To, Equal To, Greater Than Or Equal To, and Greater Than, sent on the API payload as lt, lte, eq, gte, and gt.

Are NULLs counted as a distinct value?

No. The measurement covers the values that are present, so a column that is entirely NULL has a distinct count of zero.

How is this different from Unique?

Distinct Count answers "how many different values are there"; Unique answers "does any value repeat". A column can hit the expected cardinality and still be full of duplicates.

Does the filter run before the count?

Yes. Only rows matching the filter contribute to the cardinality.


Anomaly Reporting

What does the anomaly message look like?

For the field '<field_name>', the distinct count is <actual>, which does not match the expected value of <value>

When a filter is set, the message ends with [filter: <expression>].

Does Distinct Count produce Record Anomalies?

No. The rule asserts one number about the dataset, so it reports a single Shape Anomaly.

Does Custom Anomaly Description work for Distinct Count?

No. The option replaces the message on Record Anomalies, and this rule emits a Shape Anomaly only.

Are there source records on the anomaly?

No. Nothing is evaluated per row. To see the values behind the number, group the column and count.


Configuration

Can I change the operator or the expected count later?

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

Why is there no Coverage setting?

The rule asserts one number about the dataset rather than evaluating rows, so there is no violation rate to threshold. The coverage field on the API payload is not supported either: omit it, or send 1 for backward compatibility, because any other value is rejected with 422 Unprocessable Entity.

What permission do I need to create or edit a Distinct Count 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.