Greater Than Check Examples

The situation: Every order must carry a total strictly above zero. Rows with 0 come from a checkout bug that saves the order before pricing runs, and the threshold itself must not pass, so Inclusive is off.

Check configuration

Payload

{
    "description": "Order total must be greater than zero.",
    "rule": "greaterThan",
    "fields": ["o_totalprice"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {"value": 0, "inclusive": false},
    "tags": ["orders", "range"],
    "additional_metadata": {"jira": "DATA-8401"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

Order 2 holds exactly 0. With Inclusive off the comparison is > 0, so the row fails. Order 4 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 o_totalprice"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is o_totalprice > 0?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Greater Than check would flag.
SELECT o.*
FROM orders o
WHERE o.o_totalprice IS NOT NULL
  AND o.o_totalprice <= 0;

The situation: Employees on the permanent contract qualify for an annual bonus once they reach 12 months of tenure. Exactly 12 months qualifies, so Inclusive is on. Temporary contracts are out of scope.

Check configuration

Payload

{
    "description": "Permanent employees in the bonus pool must have at least 12 months of tenure.",
    "rule": "greaterThan",
    "fields": ["tenure_months"],
    "container_id": 512,
    "coverage": 1,
    "filter": "contract = 'permanent'",
    "properties": {"value": 12, "inclusive": true},
    "tags": ["hr", "eligibility"],
    "additional_metadata": {"jira": "DATA-8444"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 33
}

Sample Data (filtered to contract = 'permanent')

Why the filter matters

The filter runs before the comparison, so temporary contracts are never tested against the tenure rule. Only permanent employees are evaluated.

What gets flagged

E-02 has 7 months and does not qualify. E-03 has exactly 12 and passes, because Inclusive is on. 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: contract = 'permanent'"] --> B["Read tenure_months"]
    B --> C{"Is tenure_months >= 12?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: contract = 'permanent']"]

Equivalent SQL

-- Rows the check would flag among permanent employees.
SELECT e.*
FROM employees e
WHERE e.contract = 'permanent'
  AND e.tenure_months IS NOT NULL
  AND e.tenure_months < 12;

The situation: A reconciled net_amount must stay above a floor of 100, but the value accumulates rounding through several pipeline steps. A relative tolerance of 0.1% keeps that noise from firing while still catching real shortfalls. A cleanup is in progress, so the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Reconciled net amount must be at least 100, within rounding tolerance.",
    "rule": "greaterThan",
    "fields": ["net_amount"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {"value": 100, "inclusive": true, "numeric_comparator": {"epsilon": 0.001, "as_absolute": false}},
    "tags": ["finance", "reconciliation"],
    "additional_metadata": {"jira": "DATA-8488"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data

What gets flagged

S-02 is just under the floor but falls inside the 0.1% tolerance, so it passes. S-03 and S-04 miss by far more than the margin and fail. 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 net_amount"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Add the 0.1% tolerance"]
    E --> F{"Is the adjusted value >= 100?"}
    F -->|Yes| D
    F -->|No| G["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, allowing a 0.1% tolerance.
SELECT s.*
FROM settlements s
WHERE s.net_amount IS NOT NULL
  AND (s.net_amount + abs(s.net_amount) * 0.001) < 100;