Field Count Check Examples

Three real-world scenarios that show how the Field Count check behaves in production: a stable extract that passes, a dropped column, and an added column. Field Count is a Shape-only rule, so every failure is reported as a single Shape Anomaly for the container.

Stable ExtractA Column Was DroppedA Column Was Added

The situation: A partner receives a nightly ORDERS extract with an agreed layout of nine columns. The check exists to notice the moment that layout changes, in either direction.

Check configuration

Field	Value
Rule	Field Count
Table / File	`ORDERS`
Number of Fields	`9`
Owner	(check creator)
Anomaly Assignee	(Integrations team)
Description	The ORDERS extract must hold exactly 9 fields.
Tags	`schema`, `drift`
Additional Metadata	`jira: DATA-9501`
Status	Active

Payload

{
    "description": "The ORDERS extract must hold exactly 9 fields.",
    "rule": "fieldCount",
    "fields": [],
    "container_id": 145,
    "properties": {"value": 9},
    "tags": ["schema", "drift"],
    "additional_metadata": {"jira": "DATA-9501"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

Container	Fields present	Count
`ORDERS`	o_orderkey, o_custkey, o_orderstatus, o_totalprice, o_orderdate, o_orderpriority, o_clerk, o_shippriority, o_comment	9

What gets flagged

The container holds exactly nine fields, so the check passes and no anomaly is created. This is the baseline the next two scenarios drift away from.

No anomaly

The container holds 9 fields, matching the expected count. The check passes.

Flowchart

graph TD
    A["Read the container's shape"] --> B["Count the fields: 9"]
    B --> C{"Does 9 equal the<br/>expected 9?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Report a Shape Anomaly"]

Equivalent SQL

-- The equivalent question, asked of the catalog rather than the data.
SELECT count(*) AS field_count
FROM information_schema.columns
WHERE table_name = 'ORDERS';
-- The check passes when field_count = 9.

The situation: An upstream release removed o_comment from the extract without telling the consumers. The row data still looks fine, so no value-level check fires: only the shape changed.

Check configuration

Field	Value
Rule	Field Count
Table / File	`ORDERS`
Number of Fields	`9`
Owner	(check creator)
Anomaly Assignee	(Integrations team)
Description	The ORDERS extract must hold exactly 9 fields.
Tags	`schema`, `drift`
Additional Metadata	`jira: DATA-9501`
Status	Active

Payload

{
    "description": "The ORDERS extract must hold exactly 9 fields.",
    "rule": "fieldCount",
    "fields": [],
    "container_id": 145,
    "properties": {"value": 9},
    "tags": ["schema", "drift"],
    "additional_metadata": {"jira": "DATA-9501"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

Container	Fields present	Count
`ORDERS`	o_orderkey, o_custkey, o_orderstatus, o_totalprice, o_orderdate, o_orderpriority, o_clerk, o_shippriority	8

What gets flagged

The scan finds eight fields where nine are expected. The check reports a single Shape Anomaly for the container; the direction of the difference tells you a column was dropped rather than added.

Shape Anomaly

The container holds 8 fields, which does not match the expected count of 9.

Flowchart

graph TD
    A["Read the container's shape"] --> B["Count the fields: 8"]
    B --> C{"Does 8 equal the<br/>expected 9?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Report a Shape Anomaly<br/>for the container"]

Equivalent SQL

-- Confirming the drop against the catalog.
SELECT count(*) AS field_count
FROM information_schema.columns
WHERE table_name = 'ORDERS';
-- Returns 8; the check expected 9.

The situation: A new o_channel column was added upstream. Nothing broke immediately, but the downstream loader maps columns by position and will silently shift every value on the next run.

Check configuration

Field	Value
Rule	Field Count
Table / File	`ORDERS`
Number of Fields	`9`
Owner	(check creator)
Anomaly Assignee	(Integrations team)
Description	The ORDERS extract must hold exactly 9 fields.
Tags	`schema`, `drift`
Additional Metadata	`jira: DATA-9501`
Status	Active

Payload

{
    "description": "The ORDERS extract must hold exactly 9 fields.",
    "rule": "fieldCount",
    "fields": [],
    "container_id": 145,
    "properties": {"value": 9},
    "tags": ["schema", "drift"],
    "additional_metadata": {"jira": "DATA-9501"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

Container	Fields present	Count
`ORDERS`	o_orderkey, o_custkey, o_orderstatus, o_totalprice, o_orderdate, o_orderpriority, o_clerk, o_shippriority, o_comment, o_channel	10

What gets flagged

The scan finds ten fields where nine are expected, so the check reports a Shape Anomaly. If the addition is legitimate, the fix is to update the check's Number of Fields as part of accepting the new layout.

Shape Anomaly

The container holds 10 fields, which does not match the expected count of 9.

Flowchart

graph TD
    A["Read the container's shape"] --> B["Count the fields: 10"]
    B --> C{"Does 10 equal the<br/>expected 9?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Report a Shape Anomaly<br/>for the container"]

Equivalent SQL

-- Confirming the addition against the catalog.
SELECT column_name
FROM information_schema.columns
WHERE table_name = 'ORDERS'
ORDER BY ordinal_position;
-- Returns 10 rows; the check expected 9.

Field Count Check Examples

See Also