Your AI shouldn't be merging records. It should be voting on them.
Picture the everyday mess: a claim, three emails, an incident report and an invoice, all about the same customer problem, with no shared ID tying them together. Deciding whether they belong to one case is a Soft Join, a match made on judgment because there is no exact key to join on.
This is where teams quietly break things, usually in one of two ways.
Failure A: putting the model on the keys. If a policy number or order ID exists, join it in code. Asking a model to "decide" something a database can answer exactly is paying for a guess when you already have the answer.
Failure B: merge-and-narrate. The model gets a pile of similar documents and hands back one tidy, rewritten summary. It reads beautifully. It's also now impossible to tell what came from where, which pieces were assumed, and whether two different events were stitched into one story.
The discipline is a hard boundary between three jobs:
Similarity, overlap and shared origin only nominate. They produce candidates with reasons attached, not identity.
The model judges, narrowly. It returns a typed decision: attach, promote, alias, or keep distinct. Not a new document. Not just a confidence score.
Code writes. Only once the decision type is known, with the original evidence and its provenance kept intact.
Then, the step almost everyone skips: rejudge the reconstructed case. If nothing checks the result after the write, you haven't built judgment. You've built filing.
None of this makes a system right every time. What it does is make every join explainable. When someone asks why two records became one case, you can show the candidate, the reason, the decision and the evidence, instead of pointing at a paragraph the model wrote.
So if you have AI reconciling records anywhere in your business: can you name your exact keys? And which of those two failures are you one refactor away from?
Discover more from Leverage AI for your business
Subscribe to get the latest posts sent to your email.