How Field Count Checks Work

Definition

Asserts that the container holds exactly the configured number of fields.

Overview

The Field Count rule compares the number of fields the platform sees on a container against the number you configured. It does not read any value: the assertion is about the shape of the dataset. That makes it a cheap early-warning signal for schema drift, and the first check to fire when an upstream producer adds a column, drops one, or renames one in a way that changes the count.

Typical use cases:

Detect schema drift in a pipeline that should have a stable set of columns.
Confirm a delimited file arrived with the agreed number of columns.
Catch an upstream change that silently added or removed a field.

Field Scope

None: The rule evaluates the container itself, so there is no field to select. Because there is no per-row evaluation, the check offers neither a filter clause nor a coverage setting.

General Properties

Details

Name	Supported
Filter Allows the targeting of specific data based on conditions
Coverage Customization Allows adjusting the percentage of records that must meet the rule's conditions

Specific Properties

Field Count has one rule-specific property:

Name	Description
Number of Fields	The exact number of fields the container must hold.

Anomaly Types

Type	Supported
Record Flag inconsistencies at the row level
Shape Flag inconsistencies in the overall patterns and distributions of a field

Evaluation Flow

Every Field Count check follows the same two-step evaluation flow:

Count the fields on the container. The platform reads the shape of the table or file as the scan sees it.
Compare against the expected number. The check passes when the two match exactly, and reports a Shape Anomaly when they differ.

No Filter, No Coverage

A filter selects rows, and coverage tolerates a fraction of failing rows: neither concept applies to a rule that evaluates the container's shape rather than its contents. Both options are absent from the form, and the API rejects them: a non-empty filter, or a coverage other than 1, returns 422 Unprocessable Entity.

Exactly, Not At Least

The comparison is an equality. A container with one field too many fails just as a container with one field too few does. That is what makes the rule useful for detecting drift in either direction, and also what makes it noisy on tables that legitimately gain columns over time.

Renames Only Show Up When the Count Changes

A field renamed in place leaves the count untouched, so Field Count stays silent. Use Expected Schema when the names and types matter, not just how many there are.