Introduction to the Expected Schema Check
The Expected Schema check asserts that a container carries the fields you declared, each still holding the type recorded on its profile, and optionally nothing else. It is the precise counterpart to Field Count: where that rule notices how many columns exist, this one notices which ones and of what type.
This section is the complete guide to the check. The Deep Dive covers the definition, properties, and full evaluation semantics, explains how anomalies are reported, walks through production examples, and collects best practices; the How-tos are step-by-step tutorials for creating, editing, and deleting a check; the API page documents the payload for programmatic use; and the FAQ answers the most frequent questions.
Next Steps
-
How It Works
The complete reference: definition, container scope, the declared field list, the extra-fields toggle, and why filters and coverage do not apply.
-
Anomaly Reporting
What the Shape Anomaly reports, how to read it, and why per-row reporting does not apply.
-
Examples
Three production scenarios: a stable contract, a type change, and an unexpected column.
-
Best Practices
Guidelines for declaring the contract, choosing the extra-fields policy, and pairing with Field Count.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.
-
Create a Check
Step-by-step tutorial for creating an Expected Schema check on a container.
-
Edit a Check
Step-by-step tutorial for changing the declared fields or the extra-fields policy.
-
Delete a Check
Step-by-step tutorial for archiving a check and deleting it permanently.
-
Troubleshooting
Common problems with type changes, extra columns, renames, and anomaly reporting.
-
API
Payload shape and field notes for creating an Expected Schema check programmatically.
-
FAQ
Short answers to questions about declared types, extra fields, renames, and anomaly reporting.