The record exists and the meaning does not
A manufacturer runs an AI system over its order data and gets answers nobody can act on. Two of the three plants call the same part a 'finished good' and a third calls it a 'replenishment item'. The planning system holds four customer identifiers for three of the largest accounts. Nobody has ever decided whether a 'quantity' field means units, cases or pallets, because in each system it means whatever the local team needed it to mean that year.
The data exists. The records are complete enough to query and the volume is adequate. What is missing is the part that would let any two people agree on what the records mean, and that has to come from the business, because it is a set of commercial decisions rather than a technical discovery. A CDO cannot derive it from a schema. The commercial owner of the process has to state it, and then somebody has to own it after that person has moved on.
Three faults that are routinely mistaken for one
Data quality programmes tend to treat inconsistency, duplication and absent ownership as a single condition. They behave differently, they have different owners, and conflating them produces months of cleaning that changes nothing.
| Fault | What it looks like | Who can actually fix it |
|---|---|---|
| Inconsistent definition | The same term carries different meanings in different systems or teams. | The function that owns the process and its commercial terms. |
| Duplicated entity | Several records describe one real-world thing, with no rule for choosing between them. | Data engineering, once the business states the matching rule. |
| Absent ownership | No named person is answerable for whether a field is right, and nobody is told when it changes. | Governance and the accountable executive, not the data team. |
The third is the expensive one and the least discussed. A duplicate can be merged by a rule and an inconsistent term resolved by a decision, but a field nobody owns will drift again within two quarters, and the drift stays invisible until a decision is taken on the wrong version of it.
Where the ambiguity comes from, separated
The causes divide into four layers, and each has to be addressed by the group that controls it.
- Process. Two teams both own part of the same transaction and both change it. Without a rule about which change wins, the record is a political document.
- Data. Identifiers issued locally, inherited from an acquired system, or assigned twice under different conditions. Nothing is wrong with the values; the identity of the thing they describe is undecided.
- Organisation. The term has an owner in one function and none in another, so it acquires meanings from whoever last extended it.
- Technology. Several systems hold a partial copy, each authoritative for something, and no component holds the whole. This is the layer most projects start from, which is why they so often reproduce the inconsistency more efficiently.
What a language model can and cannot resolve
The boundary is regularly drawn in the wrong place. A model is genuinely useful in two situations: reading a structured fact out of prose, and proposing a candidate meaning for an unfamiliar field value. Given a thousand records in mixed formats it will propose which identifiers look like the same entity, and it will be right often enough to save weeks.
It cannot supply the missing decision. Whether 'active customer' includes accounts with no order in eleven months is a question about commercial policy, and the two defensible answers produce different reports and different decisions. A model picks the more frequent pattern, which is the more frequent error rather than the right answer.
There is a second limit. A model applied to undefined data does not fail loudly. It produces confident output derived from the duplicates, the drifting terms and the ambiguous quantities, so the failure appears as business surprise rather than as a technical incident, as argued in why an AI agent needs more than database access.
The sequence that actually changes the position
- Pick one entity the business already argues about — customer, part, contract, site — and write its definition as a single paragraph in the words the business uses, not the words the warehouse uses.
- Name one person accountable for that definition, and one for each system that holds a copy. Ask them what rule they apply when two sources disagree.
- Record which fields are authoritative in which system, and which have no authoritative source. The second list is usually the interesting one.
- Identify the locally issued identifiers and decide the matching rule before any deduplication runs, because deduplication without a rule destroys evidence rather than cleaning data.
- Version the definitions and attach a change process, so the next release of a source system forces a review rather than a silent divergence.
This takes weeks rather than months, because it is five decisions by five people who already hold the knowledge. The method of running those conversations is described in mapping a business process before you build the agent.
How you will know the definitions are real
Test them against the business rather than the schema. Ask four people in three functions to define the same term from memory and compare the answers; agreement is a baseline, not a target. Ask a process owner which system is authoritative for the field that matters most there, and record the proportion who can answer.
Then watch the measure that reflects all of it: the rate at which transactions are corrected after first being recorded, for the same process, over the same period, before and after. If the semantic work is real, that rate moves down. If it does not, the definitions were documented and not adopted — the more common outcome, and one that calls for an organisational rather than a technical response.
The decision this leaves with the executive
The choice is whether to fund the definition work explicitly, or to let it emerge as a by-product of whatever gets built first. The second path always looks cheaper and reliably produces a system whose behaviour nobody can explain, including the people who commissioned it.
The defensible middle position is to treat a definition as a deliverable with an owner, a version and a review date, on the same footing as an interface. That is the difference between a business that has a shared context and one that has several systems and an opinion. The broader pattern is set out in from fragmented enterprise data to a shared business context.