Max Length Check Examples

The situation: The addresses table stores a two-letter country code. Values longer than two characters mean a country name or a padded value was written into the code column, which breaks every join against the country reference table.

Check configuration

Payload

{
    "description": "Country code must be at most 2 characters.",
    "rule": "maxLength",
    "fields": ["country_code"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {"value": 2},
    "tags": ["reference", "format"],
    "additional_metadata": {"jira": "DATA-8601"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

What gets flagged

Address A-002 holds a three-letter code. A-004 is NULL and passes without firing an anomaly. Coverage is 100%, so the failing row is reported as a Record Anomaly, and the message echoes the measured length.

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Read country_code"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is the length <= 2?"}
    E -->|Yes| D
    E -->|No| F["Flag row.<br/>Record Anomaly per failing row."]

Equivalent SQL

-- Rows the Max Length check would flag.
SELECT a.*
FROM addresses a
WHERE a.country_code IS NOT NULL
  AND length(a.country_code) > 2;

The situation: Records synced to an external CRM must fit its 100-character description column; anything longer is silently truncated on their side. Records that are not synced can hold any length and are out of scope.

Check configuration

Payload

{
    "description": "Synced descriptions must fit the CRM's 100-character limit.",
    "rule": "maxLength",
    "fields": ["description"],
    "container_id": 512,
    "coverage": 1,
    "filter": "sync_to_crm = true",
    "properties": {"value": 100},
    "tags": ["integration", "format"],
    "additional_metadata": {"jira": "DATA-8644"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 29
}

Sample Data (filtered to sync_to_crm = true)

Why the filter matters

The filter runs before the measurement, so records that are never synced are not tested against the external limit. Only synced rows are evaluated.

What gets flagged

R-02 exceeds the CRM's column limit and would be truncated on delivery. 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: sync_to_crm = true"] --> B["Read description"]
    B --> C{"Is the length <= 100?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: sync_to_crm = true]"]

Equivalent SQL

-- Rows the check would flag among synced records.
SELECT r.*
FROM records r
WHERE r.sync_to_crm = true
  AND r.description IS NOT NULL
  AND length(r.description) > 100;

The situation: A legacy note column holds pasted content well beyond the 500 characters the new schema allows. A cleanup job is trimming them, so a small fraction of oversized rows is expected and the check tolerates up to 0.5% failures.

Check configuration

Payload

{
    "description": "Notes must fit the 500-character schema limit.",
    "rule": "maxLength",
    "fields": ["note"],
    "container_id": 733,
    "coverage": 0.995,
    "filter": null,
    "properties": {"value": 500},
    "tags": ["legacy", "format"],
    "additional_metadata": {"jira": "DATA-8688"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data

What gets flagged

Notes N-02 and N-03 still hold pasted content beyond the limit. N-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 note"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is the length <= 500?"}
    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 n.*
FROM notes n
WHERE n.note IS NOT NULL
  AND length(n.note) > 500;