Is Address Check Examples

The situation: A carrier integration needs a road, a city, and a post code on every shipping address. Rows missing any of the three are rejected at label purchase, which strands the order.

Check configuration

Payload

{
    "description": "Shipping addresses must include a road, a city, and a post code.",
    "rule": "isAddress",
    "fields": ["shipping_address"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {"required_labels": ["road", "city", "postcode"]},
    "tags": ["addresses", "completeness"],
    "additional_metadata": {"jira": "DATA-9401"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 26
}

Sample Data

What gets flagged

Order O-002 carries only a city, with no road and no post code. O-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["Parse shipping_address"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Are road, city and<br/>post code all present?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Is Address check would flag: addresses missing a required part.
SELECT o.*
FROM orders o
WHERE o.shipping_address IS NOT NULL
  AND NOT (
        o.shipping_address LIKE '%<road>%'
    AND o.shipping_address LIKE '%<city>%'
    AND o.shipping_address LIKE '%<post code>%'
  );

The situation: Domestic addresses must also carry a state, which most other countries do not use. The rule is scoped with a filter so international rows are evaluated by a separate, looser check.

Check configuration

Payload

{
    "description": "Domestic billing addresses must include a road, a city, a state, and a post code.",
    "rule": "isAddress",
    "fields": ["billing_address"],
    "container_id": 512,
    "coverage": 1,
    "filter": "country = 'US'",
    "properties": {"required_labels": ["road", "city", "state", "postcode"]},
    "tags": ["addresses", "completeness"],
    "additional_metadata": {"jira": "DATA-9444"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 26
}

Sample Data (filtered to country = 'US')

Why the filter matters

The filter runs before the parsing, so addresses from countries that do not use states are never tested against this rule. Only domestic rows are evaluated.

What gets flagged

A-02 carries a road, a city, and a post code, but no state, which the domestic rule requires. 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: country = 'US'"] --> B["Parse billing_address"]
    B --> C{"Are all four required<br/>parts present?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: country = 'US']"]

Equivalent SQL

-- Rows the check would flag among domestic accounts.
SELECT a.*
FROM accounts a
WHERE a.country = 'US'
  AND a.billing_address IS NOT NULL
  AND NOT (
        a.billing_address LIKE '%<road>%'
    AND a.billing_address LIKE '%<city>%'
    AND a.billing_address LIKE '%<state>%'
    AND a.billing_address LIKE '%<post code>%'
  );

The situation: A legacy CRM export left partial addresses in contact_address. An enrichment job is completing them, and a small fraction is expected to stay partial until it finishes, so the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Contact addresses must include at least a road and a city.",
    "rule": "isAddress",
    "fields": ["contact_address"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {"required_labels": ["road", "city"]},
    "tags": ["legacy", "addresses"],
    "additional_metadata": {"jira": "DATA-9488"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data

What gets flagged

Contacts C-02 and C-03 carry only a city or a placeholder, with no road. C-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["Parse contact_address"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Are road and city<br/>both present?"}
    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 c.*
FROM contacts c
WHERE c.contact_address IS NOT NULL
  AND NOT (
        c.contact_address LIKE '%<road>%'
    AND c.contact_address LIKE '%<city>%'
  );