Matches Pattern Check Examples

The situation: Every order carries a reference shaped ORD- followed by four digits. Rows that hold a bare number, a legacy prefix, or free text break the integration that parses the reference downstream. The whole value must match, so the expression is anchored.

Check configuration

Payload

{
    "description": "Order reference must follow the ORD-0000 format.",
    "rule": "matchesPattern",
    "fields": ["order_ref"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {"pattern": "^ORD-[0-9]{4}$"},
    "tags": ["orders", "format"],
    "additional_metadata": {"jira": "DATA-9101"},
    "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 a bare number with no prefix. Because the expression is anchored, a value that merely contains four digits does not pass. 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 order_ref"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Does it match<br/>^ORD-[0-9]{4}$?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Matches Pattern check would flag.
SELECT o.*
FROM orders o
WHERE o.order_ref IS NOT NULL
  AND o.order_ref NOT RLIKE '^ORD-[0-9]{4}$';

The situation: Addresses in the US country carry a five-digit ZIP, optionally followed by a four-digit extension. Addresses in other countries use different formats and are excluded with a filter.

Check configuration

Payload

{
    "description": "US addresses must carry a valid ZIP code.",
    "rule": "matchesPattern",
    "fields": ["postal_code"],
    "container_id": 512,
    "coverage": 1,
    "filter": "country = 'US'",
    "properties": {"pattern": "^[0-9]{5}(-[0-9]{4})?$"},
    "tags": ["addresses", "format"],
    "additional_metadata": {"jira": "DATA-9144"},
    "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 match, so addresses in other countries are never tested against the ZIP format. Only US rows are evaluated.

What gets flagged

AD-02 holds four digits instead of five. AD-03 uses the extended form, which the optional group accepts. 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["Read postal_code"]
    B --> C{"Does it match the ZIP pattern?"}
    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 US addresses.
SELECT a.*
FROM addresses a
WHERE a.country = 'US'
  AND a.postal_code IS NOT NULL
  AND a.postal_code NOT RLIKE '^[0-9]{5}(-[0-9]{4})?$';

The situation: A legacy asset_tag column mixes the current AT-000000 format with values from three retired systems. A rewrite job is converting them, and a small fraction is expected to remain in the old shape until it finishes, so the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Asset tag must follow the AT-000000 format.",
    "rule": "matchesPattern",
    "fields": ["asset_tag"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {"pattern": "^AT-[0-9]{6}$"},
    "tags": ["assets", "format"],
    "additional_metadata": {"jira": "DATA-9188"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data

What gets flagged

Assets AS-02 and AS-03 still carry retired formats. AS-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 asset_tag"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Does it match<br/>^AT-[0-9]{6}$?"}
    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 a.*
FROM assets a
WHERE a.asset_tag IS NOT NULL
  AND a.asset_tag NOT RLIKE '^AT-[0-9]{6}$';