A canonical people index for legal-tech
A legal-tech company automating estate casework has a problem every records-heavy domain shares: the same human being appears across documents as Katherine J. Smith, Kathy Smith, and K. Smith, with dates of birth that sometimes agree. Their system needs one canonical record per person, because in estate law, linking two different people, or splitting one person in two, is not a display bug. It changes who inherits.
The design
Their architecture makes Infino the canonical people index: a person is globally unique in the index, and every other system maps into it. The interesting part is that they modeled entity resolution as a retrieval problem rather than a batch-dedup pipeline:
- Candidate generation is hybrid search. A new name mention queries the index with fuzzy term matching (spelling variants, initials) and vector similarity (semantic/phonetic name representations) in one query, over the same file.
- Disambiguation is structured. Date-of-birth and other attributes filter the candidate set, SQL predicates on the same index the search ran against, not a second system.
- Humans make the call. The system never auto-links or auto-creates a person. It ranks candidates; a case officer confirms. The retrieval engine’s job is to make the shortlist small and never miss the true match.
Why one engine matters here
The classic build for this is three systems: a fuzzy-text engine, a vector store, and a database for the structured filters, plus glue code to merge three candidate lists with three different score scales. Every seam is a place where the true match can fall out of the shortlist.
Running fuzzy text, vectors, and structured predicates as one query against one index removes the seams. Ranking is fused in one place, filters apply before the shortlist is cut, and there is a single index to audit when someone asks "why was this candidate ranked first?", a question that, in this domain, gets asked under oath.