Applied Research

Finding the matches everyone else missed

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.

Work in progress. Preprint published, paper under peer review.

One person. Two records. Nobody notices.

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.

Your business has this problem right now

Same technique, lower stakes, cleaner data. The commercial version is where this research is headed — it isn't there yet.

Three ideas, nothing complicated

01

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.

02

Weigh everything together

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.

03

Show the working

Every score comes with the reasons behind it. You can see why the software thinks two records match, and disagree with it.

The case that showed us the problem

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.

Record One · Example
John Smith
Missing since April 1981
Southern California
Male · 52
Record Two · Example
"John Smyth"
Filed April 1981
Southern California
Male · est. 38–48
1
Letter different in the name
45mi
Apart
~10 yrs
Both records sat there, unmatched

From one state to fifty

01

Getting it out of Florida

It's been tested on Florida records. Every state keeps its data differently, so making it work nationwide is the next real hurdle.

02

Connecting databases that don't talk

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.

03

Reaching the places with the biggest gaps

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.

It suggests. People decide.

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.

Preprint — SocArXiv · Paper under peer review
[email protected]