Every company past a certain size has the same quiet problem. One customer exists four times. The CRM knows them as Robert J. Okafor, billing has Bob Okafor, the support desk typed Rbert Okafor, and a 2019 acquisition brought in a sixth record nobody has touched since. Revenue reporting counts them separately. Fraud models treat them as strangers. The AI assistant you just deployed answers questions about all six as though they were unrelated.
Exact matching finds the easy cases and misses the expensive ones. What works is a sequence: deterministic rules where identifiers are reliable, probabilistic scoring where they are not, and graph traversal where neither is enough on its own but the connections between records settle it.
The pipeline, the evidence trail, and the human process around the close calls.
Rules first, because they are cheap, explainable and correct where identifiers are reliable. Normalise, then match on the fields that genuinely identify a person or company, and know exactly where the rules stop working.
String similarity, field weighting and a calibrated threshold, so a near match becomes a score rather than a guess. Jaro-Winkler for typos, token methods for reordering, phonetic methods where they earn their place.
The cases pairwise comparison cannot reach. Two records that share nothing directly but connect through a third: same address, same device, same employer. Connected components over the match graph resolve clusters, not just pairs.
The naive version compares every record against every other and dies at a million rows. Blocking narrows the candidate set without losing the matches that matter, and getting the blocking keys right is most of the engineering.
Merging is not deleting. Every golden record keeps which source rows contributed, which rule or score caused the merge, and when. That lineage is the difference between a system compliance signs off and one they refuse.
The band between the thresholds is where humans belong. We build the queue, the interface and the feedback loop so the reviewers' decisions improve the model instead of disappearing into a spreadsheet.
Every engagement opens with your data and your question, never a slide deck.
Kickstart
$500
Deployment
Customscoped to your data
Embedded
Customfull time
The 60-day guarantee. If a deployed solution is not delivering in 60 days, we keep working at no charge until it does.
That depends on your data, and any number quoted before seeing it is marketing. What we commit to is measuring it honestly: precision and recall against a labelled sample, reported separately, with the false positives shown to you rather than averaged away.
Yes. The pipeline runs in your environment, on your infrastructure. For teams who want a resolution pass without standing up a graph database at all, Bridgr builds the graph on the fly from your files and discards it afterwards.
They are the expensive error, so the design is asymmetric on purpose. The upper threshold merges automatically, the lower one rejects, and everything between goes to a human. Every merge is reversible because the lineage is kept.
Not necessarily. The deterministic and probabilistic stages run in Python or Spark. The graph stage needs a graph, but that can be an in-memory one for a batch run. Neo4j earns its place when resolution is continuous and the graph is queried for other things too.
Directly. Retrieval over unresolved records returns four partial answers about the same customer and no way to tell. Resolution is the prerequisite for a knowledge graph that an LLM can be trusted to read.
Or email info@eastridge-analytics.com
