Not Empty Check Examples

The situation: A customer import writes '' rather than leaving the column unset when a name is missing. Every completeness count says the column is fully populated, and the anomaly only surfaces when a report groups by customer name and produces a blank row at the top.

Check configuration

Payload

{
    "description": "The customer name must never be blank.",
    "rule": "notEmpty",
    "fields": ["customer_name"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": null,
    "tags": ["completeness", "customer-data"],
    "additional_metadata": {"jira": "DATA-11000"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

C-002 holds an empty string written by the import, so it is reported. C-004 has no value at all, which this rule passes: catching that is Not Null's job, and running both checks on this column is what the situation calls for. Coverage is 100%, so the failing row is reported as a Record Anomaly.

Flowchart

graph TD
    A["Read customer_name"] --> B{"Is the value present?"}
    B -->|No| C["Row passes"]
    B -->|Yes| D{"Does it hold a<br/>non-space character?"}
    D -->|Yes| C
    D -->|No| E["Flag row"]

Equivalent SQL

-- Rows the Not Empty check would flag.
SELECT c.*
FROM customers c
WHERE c.customer_name IS NOT NULL
  AND length(trim(c.customer_name)) = 0;

The situation: A fixed-width extract pads every field to a set width. Where a reference code is absent, the extract writes spaces rather than nothing, and those rows look populated in every count while joining to nothing downstream. Rows still in staging are excluded, because they are padded on purpose until the transform runs.

Check configuration

Payload

{
    "description": "A processed reference code must not be blank.",
    "rule": "notEmpty",
    "fields": ["reference_code"],
    "container_id": 512,
    "coverage": 1,
    "filter": "load_stage = 'processed'",
    "properties": null,
    "tags": ["completeness", "fixed-width"],
    "additional_metadata": {"jira": "DATA-11021"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data (filtered to load_stage = 'processed')

Why the filter matters

The filter runs before the evaluation, so records still in staging, where padding is expected, are never checked and cannot inflate the violation count.

What gets flagged

R-02 holds only padding. Spaces are stripped before the value is judged, so it counts as empty even though a plain <> '' comparison would let it through. The highlighted cell is what identifies it, since spaces and an empty string look the same on screen. The message ends with the filter that scoped the evaluation.

Flowchart

graph TD
    A["Apply filter: load_stage = 'processed'"] --> B["Read reference_code"]
    B --> C{"Does it hold a<br/>non-space character?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: load_stage = 'processed']"]

Equivalent SQL

-- Rows the check would flag.
SELECT r.*
FROM records r
WHERE r.load_stage = 'processed'
  AND r.reference_code IS NOT NULL
  AND length(trim(r.reference_code)) = 0;

The situation: Each order carries an array of line items. An order with an empty array made it through the pipeline without any lines attached, which means the order total has nothing behind it. Here the rule runs on an array field, so it asserts the list holds at least one entry.

Check configuration

Payload

{
    "description": "Every order must carry at least one line item.",
    "rule": "notEmpty",
    "fields": ["line_items"],
    "container_id": 733,
    "coverage": 1,
    "filter": null,
    "properties": {"is_element_context": true},
    "tags": ["completeness", "orders"],
    "additional_metadata": {"jira": "DATA-11043"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data

What gets flagged

O-02 carries an empty array and is reported. O-04 has no array at all, which passes, the same as any other unset value. Note that an array holding a single empty string would also pass: on an array field the rule asks whether the list has entries, not whether those entries carry content. For that, a Min Length check on the same field with Array Element Context enabled evaluates each element. Because the rule evaluates the column as a whole here, the result is a Shape Anomaly rather than per-row anomalies.

Flowchart

graph TD
    A["Read line_items"] --> B{"Is the array present?"}
    B -->|No| C["Row passes"]
    B -->|Yes| D{"Does it hold at<br/>least one element?"}
    D -->|Yes| C
    D -->|No| E["Count the row as failing"]
    C --> F["Shape Anomaly if any row failed"]
    E --> F

Equivalent SQL

-- Rows the check would flag.
SELECT o.*
FROM orders o
WHERE o.line_items IS NOT NULL
  AND size(o.line_items) = 0;