A record match should show its evidence

Sooner or later most data projects have to answer a simple-sounding question: is this record the same person, company, or property as that one? The two records come from different systems, typed by different people, with no shared ID between them. One says “Robert J. Smith,” the other says “Bob Smith Jr.” Same street, different unit number.

Teams usually treat this as a lookup and expect a yes or a no. It is not a lookup. It is a judgment, and the systems that hold up over time are the ones built to show how each judgment was made.

A match is a claim, not a fact

When two records share a name, that is evidence. When they also share an address, a middle initial, and a plausible age, that is more evidence. None of it is proof. Common names collide, people move, and clerks abbreviate. Somewhere in every matching system is a line where enough evidence becomes “match,” and that line was chosen by someone.

The failure we see most often is a system that hides that line. It stores the match as if it were a fact, drops the reasons, and hands downstream users a clean join. Everything looks fine until someone acts on a wrong match, and then nobody can say why the system believed it. The fix starts with naming the output honestly: a candidate match, with the evidence that produced it attached.

What to keep with every match

• The source records themselves, or a stable link to them, so a reviewer can read what was actually matched instead of a summary of it.
• The fields that agreed and the fields that did not. A match on name and address with a conflicting date tells a different story than a match on name alone.
• Which rule, model, or version of either made the call. When the matching logic changes, you want to know which old matches came from the old logic.
• What a person decided about it, and when. A confirmed match and an unreviewed one should never look the same on screen.

This is the same discipline as keeping facts and derived values apart, which we wrote about in store the facts, derive the rest. The source records are facts. The match is derived, and a derived value you cannot explain is a liability.

Where AI fits, and where it does not

Language models are good at the messy part of matching: recognizing that two spellings are the same name, reading a free-text notice, pulling an address out of a paragraph. We use them that way. What we do not do is let a model’s confidence stand in for evidence. “The model said yes” is not a reason a reviewer can check. “The model extracted this address from this notice, and it matches this parcel” is.

So the model’s job is to produce evidence, and the record of the match says which evidence it produced. The same instrumentation habits from what to instrument on an AI feature apply here: keep the input, the output, and the version, so a bad match can be traced rather than argued about.

How this shaped Tideledger

Tideledger is a matching system at its core. It collects public obituary records each morning and cross-references every name against county property and probate filings. A shared name between an obituary and a property record is a lead, not a conclusion, so the match arrives with its context: the property holdings, the published probate notice when there is one, and room for the person reviewing it to annotate it and move it through their own workflow. The decision about what a match means stays with the attorney, investor, or title officer who knows the county.

If your team is joining records across systems, the first useful step is small. Pick ten matches your system made last month and ask whether anyone can explain each one from what was stored. If the answer is no, the matching logic is not the first thing to fix; the record of it is. That is the kind of question we work through in an AI assessment, before the matches start driving decisions.