Not Negative Check Examples

The situation: Prepaid accounts cannot go below zero: the platform blocks a charge that would overdraw them. A negative balance therefore means a settlement job ran twice or applied a charge out of order. Zero is perfectly valid.

Check configuration

Payload

{
    "description": "Prepaid account balance must not be negative.",
    "rule": "notNegative",
    "fields": ["balance"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {},
    "tags": ["finance", "range"],
    "additional_metadata": {"jira": "DATA-8301"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

Account A-003 carries a negative balance, which the platform should never allow. A-002 holds zero and passes, because Not Negative accepts zero. A-004 is NULL and passes without firing an anomaly. Coverage is 100%, so the failing row is reported as a Record Anomaly.

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read balance"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is balance >= 0?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Not Negative check would flag.
SELECT a.*
FROM accounts a
WHERE a.balance IS NOT NULL
  AND a.balance < 0;

The situation: Warehouses that do not allow backorders must never report a negative stock level. Warehouses configured for backorders legitimately go negative and are excluded with a filter.

Check configuration

Payload

{
    "description": "Stock levels must not be negative where backorders are disabled.",
    "rule": "notNegative",
    "fields": ["on_hand"],
    "container_id": 512,
    "coverage": 1,
    "filter": "allows_backorder = false",
    "properties": {},
    "tags": ["inventory", "range"],
    "additional_metadata": {"jira": "DATA-8344"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 29
}

Sample Data (filtered to allows_backorder = false)

Why the filter matters

The filter runs before the comparison, so warehouses that allow backorders are never tested. Only rows where a negative level is impossible are evaluated.

What gets flagged

SKU-02 shows a negative level in a warehouse that cannot backorder, which points at a double-counted shipment. SKU-03 holds zero and passes. Coverage is 100%, so the failure is reported as a Record Anomaly, and the message ends with the filter that scoped the evaluation.

Flowchart

graph TD
    A["Apply filter: allows_backorder = false"] --> B["Read on_hand"]
    B --> C{"Is on_hand >= 0?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: allows_backorder = false]"]

Equivalent SQL

-- Rows the check would flag where backorders are disabled.
SELECT s.*
FROM stock_levels s
WHERE s.allows_backorder = false
  AND s.on_hand IS NOT NULL
  AND s.on_hand < 0;

The situation: A legacy import writes days_open with occasional negative values produced by a broken date subtraction. A fix is rolling out, so a small fraction of bad rows is expected and the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Days open must not be negative.",
    "rule": "notNegative",
    "fields": ["days_open"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {},
    "tags": ["support", "plausibility"],
    "additional_metadata": {"jira": "DATA-8388"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 52
}

Sample Data

What gets flagged

Tickets T-02 and T-03 come from the legacy import with negative durations. T-04 is NULL, so it passes without firing an anomaly but still counts in the scanned total. Only 50% of the rows pass, which is below the 99.5% coverage threshold, so the check reports a single Shape Anomaly for the dataset with a sample of the offending rows. Coverage below 100% does not produce Record Anomalies.

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read days_open"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is days_open >= 0?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Passing rate falls below the 99.5%<br/>coverage, so one Shape Anomaly is reported."]

Equivalent SQL

-- Rows the check would flag.
SELECT t.*
FROM tickets t
WHERE t.days_open IS NOT NULL
  AND t.days_open < 0;