Field Count Best Practices

Guidelines for getting reliable signal from Field Count checks while keeping the noise (and the maintenance) low.

Pair it with Expected Schema for the full picture

Field Count answers "how many", Expected Schema answers "which ones, and of what type". Field Count is cheaper and catches additions and removals; Expected Schema catches renames and type changes that leave the count intact. Most pipelines that care about drift want both.

Keep the number current with the contract, not with the data

When a column is legitimately added, updating this check is part of shipping that change. A Field Count check nobody updates becomes a permanent anomaly that trains people to ignore the queue.

Expect it on evolving tables

Tables that gain columns as the product grows are a poor fit for an equality on the count. Reserve the rule for interfaces that are supposed to be stable: delivered files, integration contracts, published extracts.

Record the reason for the number in the description

"Nine fields, matching the agreed extract layout" tells the next reader whether an anomaly means the file is wrong or the contract changed. A bare number does not.

Route the anomalies to the right people

A failure usually points at the system that produced the value, not at the warehouse. Set an Anomaly Assignee from the team that owns that producer, and tag the check so related checks are easy to find.