Assume the data is wrong
Names get misspelled. Dates get rounded. Instead of demanding an exact match, the software asks how close two records are and scores it.
I built forensic software that spots when two records (missing person vs unidentified bodies) are describing the same person — even when the name is spelled wrong, the dates don't line up, and the records live in systems that never talk to each other. I quickly realized that the software analysis engine I built can be used on databases in business across all industries.
It started with a cold case in California which took 40 years to solve. Turns out, two records sat unmatched in a database for a decade due to a misspelling in the person's name. That showed us the real problem was the databases, not the evidence. I built the software and tested it against Florida missing person and unidentified body records. The same problem shows up in almost every business database, regardless of industry. This software engine looks at patterns in a unique way to quickly identify errors.
Someone types a name wrong. A date gets entered as a placeholder. One record goes into one system, the other goes into another. Now you have two files describing the same person, and nothing in either system will ever connect them.
Most software only compares records when they're first created. Nobody goes back and re-checks the old ones against everything added since. So the match just sits there.
Same technique, lower stakes, cleaner data. The commercial version is where this research is headed — it isn't there yet.
Names get misspelled. Dates get rounded. Instead of demanding an exact match, the software asks how close two records are and scores it.
No single field decides it. Name, dates, location, and description all contribute. A weak name plus a strong location can still be a real match.
Every score comes with the reasons behind it. You can see why the software thinks two records match, and disagree with it.
Two records in California, filed the same month, 45 miles apart, one letter different in the name. A human eventually connected them — about a decade later. Nothing in either system had ever compared them.
That was the point. The evidence was already there. The databases just weren't talking. We built the software to close that gap, then tested it on real Florida records. Names below are made up. The case is real.
It's been tested on Florida records. Every state keeps its data differently, so making it work nationwide is the next real hurdle.
Tribal, county, state and federal systems were never built to share. Reaching across all of them is the difference between finding some matches and finding the ones that matter.
Cases concentrate in specific areas — reservations among them — where reporting systems are weakest and records are least likely to be compared. That's where this needs to work first.
The software never confirms anything. It hands a person a ranked list and the reasons behind it. Every result gets checked by a human before anyone acts on it. That's true in forensics and it's true in your CRM.