“Schema drift” is a technical name for a very ordinary problem: over time, the shape of the questions you ask stops matching the shape of the data you’ve stored. Forms get edited. Spreadsheets gain columns. A field changes meaning. Eventually last year’s answers and this year’s answers can’t be read the same way.
How drift happens
Drift rarely comes from one big change. It accumulates:
- A form is copied and tweaked. The copy asks for “Mobile” instead of “Phone”, and now there are two versions of the same question.
- A field changes meaning. “Address” used to mean the billing address; now it means the service address. Nobody updated the old entries.
- A field is added or removed in place. Old submissions don’t have the new field, and some tools quietly reinterpret them against the new layout.
- Validation changes. A field that used to be optional becomes required, and older records suddenly look incomplete.
Each change is reasonable on its own. The problem is that nothing records which version of the question an answer was given to.
Why it’s expensive
Drift turns reporting into archaeology. Before you can answer a simple question — how many requests came from each city this year? — someone has to work out which forms asked for a city, how they spelled it, and whether the field meant the same thing throughout the year.
It also undermines documents. If a generated document reads from a field whose meaning has changed, the document is wrong in a way nobody notices until it matters.
How Atlas prevents drift
Atlas is built so that drift can’t creep in quietly. Three design choices do the work.
1. Fields are defined once
In Atlas, fields live in data schemas, not in individual forms. A form attaches schemas rather than redefining fields, so there’s only ever one definition of Contact Details or Service Address to keep correct.
2. Published schemas are versioned, not edited in place
Publishing a schema makes a version available to your forms. From then on, editing the schema creates a new version instead of changing the old one. That means forms you’ve already printed and data you’ve already collected keep their original shape.
3. Every form shows the version it collects
When you attach a schema to a form (or to a record schema on Enterprise), it arrives with its version number. Only published versions can be attached. You always know exactly which version of a question a form is asking — and therefore which version an answer was given to.
The same principle carries through to documents: in Atlas’s document templates, a template binds to a specific record schema version, so a generated document always reflects the model it was designed for.
What this looks like day to day
Say you decide Service Address should include a unit number.
- You edit the Service Address data schema and publish it. That creates a new version.
- Forms you build or update from now on can attach the new version.
- Submissions and printed forms from before the change still carry the version they were collected with, so nothing in your history is reinterpreted.
The change is deliberate and visible, rather than silent.
Recognizing drift in your own data
Drift is easiest to fix when you catch it early. Warning signs:
- The same question appears with different labels on different forms — “Phone”, “Mobile”, “Contact number”.
- Reports need a translation step before numbers can be compared across months or forms.
- Old records look incomplete because a field was added later and there’s no way to tell which records should have it.
- People ask “which version of the form is this?” when reading a submission.
- Integrations break after form edits, because a field was renamed or its meaning changed.
If any of these apply, drift has already started.
Repairing drift that’s already happened
Prevention is easier than repair, but existing drift can be contained:
- Inventory the variations. List every form and every version of each shared question.
- Choose one definition for each group of fields and build it as a data schema.
- Rebuild forms on the shared schemas, so new answers follow one definition.
- Leave old answers as they are, labelled by the form and period they came from, rather than trying to rewrite history.
- Draw a line. From a set date, all new data follows the shared definitions.
The goal isn’t to make old data perfect; it’s to stop new drift from accumulating.
Drift vs. evolution
Not every change is drift. Businesses evolve, and their data should evolve with them. The difference is whether the change is visible and traceable:
| Evolution | Drift |
|---|---|
| A new version is published deliberately | A live form is edited in place |
| Old answers keep the version they were given to | Old answers are silently reinterpreted |
| Every form shows which version it uses | Nobody can say which version a form uses |
| Changes happen in one shared definition | Changes happen form by form |
Atlas is designed to make every change an evolution rather than drift: define once, version on publish, and show the version wherever a schema is used.
A short checklist for teams
- Keep one definition for each shared group of fields.
- Publish changes deliberately rather than editing live.
- Check which version a form attaches when you update it.
- Review forms quarterly for near-duplicate questions.
A healthy habit
Treat publishing as the moment a question becomes official. Draft freely — Atlas shows a banner when a schema has unpublished changes — then publish when the shape is right. Read How schema versioning protects the data you’ve already collected for a closer look at versions, and Build once, reuse everywhere for how to organize schemas so there’s only ever one place to make a change.
