Between Check Examples

The situation: The lineitem table stores l_discount as a ratio. Any value below 0 or above 1 means the pricing engine wrote a percentage (or a negative correction) into a ratio column, which silently distorts every revenue calculation downstream. Both 0 (no discount) and 1 (fully discounted) are legitimate, so both boundaries are inclusive.

Check configuration

Payload

{
    "description": "Discount must be a ratio between 0 and 1, inclusive.",
    "rule": "between",
    "fields": ["l_discount"],
    "container_id": 214,
    "coverage": 1,
    "filter": null,
    "properties": {
        "min": 0,
        "inclusive_min": true,
        "max": 1,
        "inclusive_max": true
    },
    "tags": ["pricing", "range"],
    "additional_metadata": {"jira": "DATA-6021"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

Line 1002 holds 15, a percentage written into a ratio column. Lines with 0 and 1 sit exactly on the boundaries and pass, because both sides are inclusive. Coverage is 100%, so the failing row is reported as a Record Anomaly.

Flowchart

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

Equivalent SQL

-- Rows the Between check would flag.
SELECT l.*
FROM lineitem l
WHERE l.l_discount IS NOT NULL
  AND NOT (l.l_discount >= 0 AND l.l_discount <= 1);

The situation: Contracts on the standard tier must be worth more than 1,000 and at most 50,000. Below the floor they should have gone through self-service, above the ceiling they need an enterprise approval. The floor is exclusive (exactly 1,000 belongs to self-service) and the ceiling is inclusive (exactly 50,000 is still standard). Other tiers are out of scope.

Check configuration

Payload

{
    "description": "Standard-tier contracts must be above 1,000 and at most 50,000.",
    "rule": "between",
    "fields": ["contract_value"],
    "container_id": 640,
    "coverage": 1,
    "filter": "tier = 'standard'",
    "properties": {
        "min": 1000,
        "inclusive_min": false,
        "max": 50000,
        "inclusive_max": true
    },
    "tags": ["contracts", "range"],
    "additional_metadata": {"jira": "DATA-6104"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 26
}

Sample Data (filtered to tier = 'standard')

Why the filter matters

The filter runs before the comparison, so enterprise and self-service contracts are never tested against the standard band. Only standard-tier rows are evaluated.

What gets flagged

C-4002 is exactly 1000, and the lower boundary is exclusive, so the row fails. C-4003 is exactly 50000 and passes, because the upper boundary is inclusive. 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: tier = 'standard'"] --> B["Read contract_value"]
    B --> C{"Is contract_value > 1000<br/>AND <= 50000?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: tier = 'standard']"]

Equivalent SQL

-- Rows the check would flag on the standard tier.
SELECT c.*
FROM contracts c
WHERE c.tier = 'standard'
  AND c.contract_value IS NOT NULL
  AND NOT (c.contract_value > 1000 AND c.contract_value <= 50000);

The situation: A fleet of temperature sensors reports into sensor_readings. Physically valid values sit between -40 and 85 degrees Celsius, the operating range of the hardware. A small fraction of readings is expected to be out of range while faulty units are being replaced, so the check tolerates up to 0.5% failures. Sensors that failed to report leave the value NULL.

Check configuration

Payload

{
    "description": "Sensor readings must fall inside the hardware operating range.",
    "rule": "between",
    "fields": ["temperature_c"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {
        "min": -40,
        "inclusive_min": true,
        "max": 85,
        "inclusive_max": true
    },
    "tags": ["telemetry", "plausibility"],
    "additional_metadata": {"jira": "DATA-6233"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 52
}

Sample Data

What gets flagged

Readings R-8802 and R-8803 come from the same faulty unit and fall far outside the hardware range. R-8804 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 temperature_c"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is temperature_c >= -40<br/>AND <= 85?"}
    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 s.*
FROM sensor_readings s
WHERE s.temperature_c IS NOT NULL
  AND NOT (s.temperature_c >= -40 AND s.temperature_c <= 85);