The field that means three things
Both systems have a field called status. Both populate it correctly. They have never once meant the same thing.
Same name. Same type. Different question.
Validation checks the shape. Nothing checks what the value was answering.
Two systems can share a field name and not share its meaning. Nothing errors, because the shape is right — the string is a string and the enum is in range. What is wrong is the sense, and no validation examines sense. The divergence is found by somebody reconciling two reports by hand, usually years later.
The CRM has a field called status. So does the billing system. So does the fulfilment platform. An integration maps one to the others, because they have the same name and the same type.
In the CRM, status describes the relationship: active means the customer is engaged. In billing, it describes the account: active means invoices are being raised. In fulfilment, it describes the order: active means something is moving.
A customer can be active in one, inactive in another and absent from the third, and every one of those is correct.
No validation catches this, because there is nothing malformed to catch. The field is a string of the right length, or an enum in range. Schema validation passes. Type checking passes. Referential integrity passes. All of them examine shape, and the shape is fine — what is wrong is the sense, and no automated check examines sense.
So the mapping runs, correctly by every available measure, for years.
Every check you have examines whether the value is well formed. None examines whether it was answering the same question.
The discovery is almost always the same. Somebody reconciles two reports by hand at quarter end and the numbers do not match. The first assumption is a timing difference. The second is a filter somebody applied. The third, eventually, is that the two systems have been counting different populations since the integration was built.
By then the divergence has propagated. Downstream reports were built on one reading, decisions were taken on those reports, and correcting the mapping now changes numbers that people have already acted on.
Write down what each field means, in a sentence, before mapping it. Not the type and not the allowed values — what question the value is answering. Two sentences side by side make a mismatch obvious in seconds, and nothing else does.
Ask who populates it and when. A field set by a user, a field set by a nightly job, and a field set by a webhook are three different things wearing the same name, and they diverge under different conditions.
Reconcile on meaning, not on count. Counting both sides finds missing records. It does not find records that are present in both and mean different things. That requires sampling actual rows and reading them, which takes an afternoon and is almost never done.
- Shape validation passes because the shape is correct
- A shared name is not a shared definition, and the name is what gets mapped
- Write what question each field answers, in a sentence, before mapping it
- Record counts find missing rows; only reading rows finds wrong meanings
This describes integrations we were asked to examine, usually after somebody had noticed two reports disagreeing. Integrations nobody has questioned are not brought to us, so this says nothing about how widespread the problem is.
Reading thirty rows side by side settles it faster than any audit. Where the answer is that the integration needs rebuilding, that is what we do.
Limits
Engagement observation, not a study
Drawn from integrations somebody already suspected of a problem, which is not a representative population.
Three fields, not a taxonomy
Status, active and owner are the ones we find most often. There will be others we have not seen, and every operation has its own.
It describes data that matters
Where a field's divergence costs nothing, this can run harmlessly for years and that is a reasonable state to be in.
Questions
Would a data dictionary not solve this?
Only if it records meaning rather than type. Most dictionaries document the field's shape and its allowed values, which is exactly the part that already matches.
How do we find it in an existing integration?
Sample thirty rows that exist on both sides and read them. Not counts — the actual values, side by side, with somebody who knows each system. It takes an afternoon.
What if we find it after years?
Then the correction changes historical numbers, and that is a conversation rather than a migration. Decide what the field will mean going forward, record the date it changed, and leave the history alone rather than restating it.
Is this the same as a schema mismatch?
The opposite. A schema mismatch fails loudly and gets fixed the same day. This passes every check and survives for years, which is why it costs more.
Does a single source of truth fix it?
It helps and it does not remove the problem, because the systems consuming it still interpret. What removes the problem is agreeing what the field means, which is a conversation rather than an architecture.
Whose job is this?
Usually nobody's. It sits between the teams that own each system, and each is confident about their own definition — correctly, because each is right about their own.
Govil, A. (2026). The field that means three things. The Field Report, XONIK.