Normalization: same customer, five IDs
Every system has its own idea of a customer, a note or a date. Normalization turns them into one validated shape, and it quietly decides what your AI will say. Lessons from an AI platform for lawyers and clinicians.
Bring data in from five systems and you will find the same customer five times: under different IDs, with names spelled two ways, dates in three formats and a “status” field that means something different in each.
An AI model doesn’t notice. It reads what it is given and answers confidently. That is why the second stage of every project is normalization: turning many incompatible descriptions into one consistent, validated shape before anything smart happens.
Where we learned it
We owned the integration and data layer of an AI platform for legal and healthcare practitioners. Its assistant needed each practice’s own records: clients and patients, cases, notes, test results. Those came from case-management, practice, health-record and wellness systems, each with its own idea of what a contact, a note or a result is.
One model, enforced at the door
- One adapter per source. Each adapter speaks one system’s language, its authentication and quirks included, and nothing else.
- One typed, validated model per kind of record. Practices, people, notes and results each have one shape, checked on the way in.
- Resolvers for identifiers. Each source’s IDs and fields are mapped into the shared model, so “the same person” really is one person.
- Reject, don’t repair silently. A record that doesn’t fit fails loudly and is logged. It never slips through to the assistant as “probably fine”.
The same lesson, outside healthcare
On the AI sales-coaching product we built, two of the biggest early problems had nothing to do with AI quality. Calls were credited to the wrong salesperson, and training recordings were counted as sales calls. Both were normalization problems, and both would have misled a manager more than any model error.
Questions to ask about your own data
- If the same customer exists in two systems, which one wins, and who decided?
- What happens to a record that doesn’t fit: is it rejected, repaired, or passed on?
- Could you trace any answer your AI gives back to the records it used?
Clean, consistent data is necessary, but not enough. A system can be fed perfect records and still return a wrong answer with full confidence. Catching that is the third stage: trust.
This article is drawn from a real engagement. Client details withheld; every figure comes from the client’s own data.
Read the full case study →