Fragmented systems, five versions of the same customer

Five systems captured the same customer five different ways because their forms validated input differently. Your model reads all five and has to decide which one is true, or worse, treats them as five people.

Fragmented systems, five versions of the same customer

One real person. Five systems. Five records that are supposed to be the same customer and are not quite. The model reads all five and has to work out that they are one human, or it quietly decides they are five.

This is fragmentation, and it is one of the most common reasons an AI feature that looked fine in a pilot falls apart on real data.

Same customer, five different captures

An engineering lead who has moved close to three billion records across retail, restaurant, and accounting systems described this without dressing it up. The same customer gets captured differently in five systems because each system’s form validation is different. One requires a phone number, one does not. One splits first and last name, one keeps a single field. One normalizes the state to a two-letter code, one stores whatever the merchant typed. One dedupes on email, one allows the same person to be entered twice.

None of these systems is broken. Each did exactly what its own form told it to do. The result is five records that agree on the person and disagree on the details, and no single one of them is the truth. The truth is spread across all five, in fragments, waiting for someone to reconcile.

The model does not know they are one person

Here is the failure that follows. Hand those five records to an AI feature and it faces a problem no one told it about. Are these five customers or one. If nothing has resolved the fragments into a single entity, the model does the literal thing. It treats them as five. Now your “customers who ordered twice” logic misses a person who ordered five times across five systems. Your personalization contradicts itself, because it is drawing on whichever fragment it happened to read. Your counts are wrong in a way that never throws an error.

Or the model tries to merge them on the fly and picks wrong, because it has no rule for which fragment wins. The phone number from system A, the address from system C, the spelling of the name from system E. It assembles a customer who does not exactly exist and answers with total confidence. AI features generally need around 85% accuracy to stay reliable, and fragmentation erodes that quietly, because every fragmented entity is a small chance to count, merge, or personalize wrong.

Reconciliation is where the five become one

The fix is the same unglamorous work that a careful migration already does. Someone reconciles. A person, or a deliberately designed rule, decides how the five fragments collapse into one canonical customer. Which system is the source of truth for the address. What happens when two systems disagree on the name. How you match records that share an email but nothing else, or share a name and a city but no email at all. In this lead’s migrations, one system allowed duplicate customers and the next did not, so last write wins had to become a rule a human designed. Fragmentation is that same problem multiplied across five sources instead of two.

The reconciliation is not optional cleanup. It is the step that turns five versions of a customer into one entity the model can reason about. Skip it and the model reasons about five, forever, and no dashboard tells you it is doing so.

Pilots hide fragmentation by design

A pilot almost never shows this, because the curated slice was built from one clean source or hand-merged before the demo. The five-way split only appears when production connects all the systems at once and the same person starts arriving through five doors. That is why a feature can pass its pilot and then produce nonsense on live data. The pilot never made it choose which version of the customer was real.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two week, $2,500 engagement, we look for entities that live in more than one system and ask how they get reconciled into one. Where is the same customer captured five ways, which field is authoritative, and what rule collapses the fragments. If the answer is that nothing reconciles them, we flag it, because the model will either see five customers or invent a sixth. Finding the fragmentation in a two week diagnosis is far cheaper than watching it corrupt your counts in production.

Five systems, one person, five truths. Decide which one is real before the model decides for you.