Field Count Check FAQ
Answers to common questions about how the Field Count check evaluates a container's shape, why it has no filter or coverage, and how anomalies are reported, grouped by topic.
Behavior
Does the check look at the data?
No. It compares the number of fields on the container against the number you configured. No value is read, which is why the check is cheap and why it has neither a filter nor a coverage setting.
Is the comparison exact?
Yes. A container with one field too many fails just like one with a field missing. That is deliberate: drift in either direction is worth knowing about.
Will it catch a renamed column?
No. A rename leaves the count unchanged. Use Expected Schema when names and types matter.
Why is there no Filter Clause or Coverage?
Both are row-level concepts. This rule evaluates the container's shape, so they are absent from the form, and the API rejects a non-empty filter or a coverage other than 1 with 422 Unprocessable Entity.
Anomaly Reporting
What does the anomaly report?
A single Shape Anomaly stating that the field count does not match the expected number, with the observed count and the configured one. There is no per-row variant and no filter suffix.
Does Field Count produce Record Anomalies?
No. The rule is Shape-only: the violation belongs to the container, not to a row.
Does Custom Anomaly Description work for Field Count?
No. The option replaces the message on Record Anomalies, and this rule emits a Shape Anomaly only.
Are there source records on the anomaly?
No. Nothing is evaluated per row, so there is nothing to sample. Review the container's field list instead.
Configuration
Can I change the expected count on an existing check?
Yes. In the UI, open the check, change Number of Fields, and click Update; see Edit a Check for the full steps. Through the API, a PUT to /api/quality-checks/{id} updates properties.value. The rule type, the target container, and the associated Check Template stay immutable; see the API page for the editable/immutable matrix.
What permission do I need to create or edit a Field Count check?
The Drafter team permission on the datastore covers Draft work (creating a check as Draft or editing it while it stays Draft). Anything that puts the check into evaluation, such as creating or editing an Active check, archiving, or deleting, requires the Author team permission (or above). Viewing only requires Reporter. See Permissions for the full matrix.
Should I use Field Count or Expected Schema?
Use Field Count as a cheap tripwire for additions and removals. Use Expected Schema when the specific names and declared types are the contract. Running both is common: the first is inexpensive, the second is precise.