Equal To Check Examples

The situation: Standard-rate invoice lines are generated with a tax rate of exactly 0.2, written by the pricing service from a configuration value. Any other rate means a line was created outside that service or the configuration drifted.

Check configuration

Payload

{
    "description": "The standard tax rate must always be 0.2.",
    "rule": "equalTo",
    "fields": ["tax_rate"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {"value": 0.2, "inclusive": true},
    "tags": ["reference-data", "constant"],
    "additional_metadata": {"jira": "DATA-10101"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

Line L-002 was created manually with a different rate. L-004 is NULL, and no Numeric comparator is set, so it fails too: the check requires tax_rate to be present and equal to 0.2. Coverage is 100%, so each failing row is reported as its own Record Anomaly.

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read tax_rate"]
    B --> C{"Is tax_rate present?"}
    C -->|No| F["Flag row.<br/>Record Anomaly per failing row."]
    C -->|Yes| E{"Does tax_rate equal 0.2?"}
    E -->|Yes| D["Row passes"]
    E -->|No| F

Equivalent SQL

-- Rows the Equal To check would flag.
SELECT l.*
FROM invoice_lines l
WHERE l.tax_rate IS NULL
   OR l.tax_rate <> 0.2;

The situation: A settled batch must net to zero: credits and debits cancel out. The balance is accumulated across thousands of rows, so it lands within fractions of a cent rather than exactly on zero. An absolute tolerance of 0.01 absorbs that without hiding a real imbalance. Draft batches are excluded with a filter.

Check configuration

Payload

{
    "description": "Settled batches must net to zero, within a cent.",
    "rule": "equalTo",
    "fields": ["net_balance"],
    "container_id": 512,
    "coverage": 1,
    "filter": "status = 'settled'",
    "properties": {"value": 0, "inclusive": true, "numeric_comparator": {"epsilon": 0.01, "as_absolute": true}},
    "tags": ["finance", "reconciliation"],
    "additional_metadata": {"jira": "DATA-10144"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data (filtered to status = 'settled')

Why the filter matters

The filter runs before the comparison, so draft batches, which have not netted yet, are never evaluated. Only settled batches are tested.

What gets flagged

B-01 is off by four thousandths, inside the one-cent tolerance, so it passes. B-02 is out by more than two hundred, far beyond the margin, and fails. Coverage is 100%, so the failure is reported as a Record Anomaly, and the message ends with the filter that scoped the evaluation. Unlike the previous scenario, a settled batch with a NULL net_balance would pass here: the Numeric comparator makes an all-NULL row pass.

Flowchart

graph TD
    A["Apply filter: status = 'settled'"] --> B["Read net_balance"]
    B --> C["Apply the 0.01 tolerance"]
    C --> D{"Is the adjusted value 0?"}
    D -->|Yes| E["Row passes"]
    D -->|No| F["Flag row.<br/>Anomaly message ends with<br/>[filter: status = 'settled']"]

Equivalent SQL

-- Rows the check would flag, allowing a one-cent tolerance.
SELECT b.*
FROM batches b
WHERE b.status = 'settled'
  AND b.net_balance IS NOT NULL
  AND abs(b.net_balance) > 0.01;

The situation: A migration set schema_version to 3 on every row, but a legacy loader still writes older values on part of the table. A fix is rolling out, so a small fraction is expected to lag and the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Every row must carry schema version 3.",
    "rule": "equalTo",
    "fields": ["schema_version"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {"value": 3, "inclusive": true},
    "tags": ["legacy", "constant"],
    "additional_metadata": {"jira": "DATA-10188"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data

What gets flagged

Records R-02 and R-03 were written by the legacy loader with older versions. R-04 is NULL, and with no Numeric comparator set it fails as well, because the check requires schema_version to be present. Three of the four rows fail, so only 25% pass, well below the 99.5% coverage threshold, and 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 schema_version"]
    B --> C{"Is schema_version present?"}
    C -->|No| F["Flag row.<br/>Passing rate falls below the 99.5%<br/>coverage, so one Shape Anomaly is reported."]
    C -->|Yes| E{"Does schema_version equal 3?"}
    E -->|Yes| D["Row passes"]
    E -->|No| F

Equivalent SQL

-- Rows the check would flag.
SELECT r.*
FROM records r
WHERE r.schema_version IS NULL
   OR r.schema_version <> 3;