Schema drift arrives quietly. A source team adds a column for a new product line, renames status to account_status, or changes a numeric code to a string. Nothing in the pipeline fails on the day it happens. The failure shows up later, when a join returns fewer rows, a feature fills with nulls, or a model reads a code it has never seen.
The usual causes are ordinary:
- an application release changes a table it owns
- a vendor API adds or retires fields
- a spreadsheet export reorders or renames columns
- a migration retypes identifiers or dates
Teams catch most of it with schema checks at ingestion and with contracts between the producer and the consumer of a table. For AI work the harder case is the change that keeps the schema valid while changing what a field means.
How is schema drift different from data drift?
- Schema drift changes the structure: which columns exist, their names, and their types. Data drift changes the values inside an unchanged structure: distributions, ranges, and frequencies.
- Schema drift is usually visible to a validator at load time. Data drift needs statistics compared against a reference period.
- Both break an AI result the same way: the model reads inputs that no longer mean what they meant when it was evaluated.
Where does schema drift break in AI work?
A churn model reads account_status, which the billing team split last quarter into status and sub_status. The old column still exists and still validates, but it now carries only four of the nine codes the model was trained on. Predictions keep flowing, every row passes the schema check, and the model quietly stops seeing paused accounts.
The check that catches this compares the field profile the model was evaluated on with the profile of the new extract: distinct values, null share, and meaning confirmed by the owner. In Syntitan the preparation results are recorded with the project Version. A new extract can be diagnosed on the six axes under Ready for Raw Data, and the before-and-after comparison rerun on the same evaluation set in Ready for Model. Carrying earlier checks over to the next extract is in development. Data profiling describes the profile itself, and field mapping covers how a renamed field gets reconnected.