Entity resolution definition
Entity resolution is the process of deciding which records, within or across datasets, refer to the same real-world entity such as a person, company, product, or place, and then linking or merging them into a single canonical representation. It is needed when no reliable shared identifier exists, so identity must be inferred from imperfect attributes.
Entity resolution decides which records refer to the same real-world thing when no shared identifier tells you, then links or merges them into one canonical record. It exists because systems store the same customer or product many times under slightly different spellings. In Sanity, an entity is a single document with an immutable `_id` and every related document holds a reference to that ID, so the identity decision is made once at authoring time instead of reconstructed later by a matching job.
Entity resolution works as a pipeline of five steps, and the literature presents them in this order. First, normalization: put fields into comparable form, so casing, punctuation, nicknames, address formats, and date formats line up. Second, blocking (also called indexing): group records into candidate blocks so you only compare plausible pairs. Blocking exists because comparing every record against every other record grows quadratically with the number of records, which is covered in this survey of blocking and filtering techniques. Third, pairwise comparison and scoring: deterministic rules, probabilistic scoring, machine learning models, or, more recently, large language models decide how likely two records are to match. Fourth, clustering: turn accepted pairs into entity clusters, which forces a decision about transitivity (if A matches B and B matches C, are all three one entity?). Fifth, canonicalization, sometimes called survivorship: choose which values represent the resolved entity, producing what practitioners call a golden record, while keeping the lineage back to the source records.
One detail from the founding theory is worth carrying into any real system. Fellegi and Sunter's A Theory for Record Linkage, published in the Journal of the American Statistical Association in December 1969, classifies a record pair three ways, not two: match, non-match, or possible match requiring human review. That third outcome is why entity resolution is usually a human-in-the-loop system rather than a fully automatic batch job.
Deduplication and record linkage are both entity resolution; the difference is scope. Deduplication matches records within a single source or table, for example finding the four rows in one CRM that all describe the same hospital. Record linkage matches records across separate sources, for example joining a tax file to a benefits file with no common key. The umbrella term entity resolution covers both, and the University of Leipzig's work on large-scale entity resolution describes the task as identifying semantically equivalent entities within or between data sources, noting that data deduplication, object matching, and record linkage all name the same family of problem.
Two neighboring terms are narrower. Entity matching usually means just the pairwise decision step, which is how the recent language-model literature uses it, including Match, Compare, or Select? and Entity Matching using Large Language Models from EDBT 2025. Identity resolution is the customer-data flavor: stitching one person's records across devices, channels, and logins, which adds privacy obligations that generic entity resolution does not carry.
Entity resolution is not named entity recognition, entity linking, master data management, or fuzzy matching, though it sits next to all four and is routinely confused with them. Named entity recognition finds mentions of entities in unstructured text. Entity linking maps a mention to an entry in a
Master data management is the governance program and system of record for shared entities across a business. Entity resolution is a technique used inside it to populate and maintain that record: a method, not an operating model. Fuzzy matching and string similarity measures such as edit distance and Jaro-Winkler produce a score for a pair of values, not a decision about identity; they are signals feeding the comparison step. The same applies to semantic or vector similarity, which is useful for generating candidates during blocking but has no notion of clustering or survivorship. Finally, entity resolution is the complement of referential integrity, not a competitor to it. When a stable shared key exists and every system writes against it, there is nothing to resolve. Entity resolution is the cost of not having that key.
Sanity does not ship an entity resolution engine, and it approaches the same problem from the other end: identity is modeled at write time rather than inferred afterwards. A document in the Content Lake has an `_id` that is unique within the dataset and cannot be modified once created, so one document per real-world entity gives you a canonical record with a stable identifier. Relations use the `reference` schema type, which stores a pointer of the form `{"_type": "reference", "_ref": "<document id>"}` rather than a copy of the entity's attributes, so there is no duplicate string to reconcile later. One-to-many is an array of references.
References are strong by default, which means a referenced document cannot be deleted while something points at it, and the referring document is blocked from publishing until the referenced document is published (setting `weak: true` relaxes both). In queries, GROQ follows a reference with `->` and finds everything attached to an entity with `references('someId')`, so "what else points at this record" is one query instead of a join-and-reconcile exercise. This is the Model your business pillar of Sanity, the Content Operating System for the AI era: the intelligent backend for companies building AI content operations at scale, where the shape of your entities is declared rather than guessed at.
You can build matching and merge logic against content in Sanity, and the honest framing is that Sanity supplies the events, the query layer, and the write path while the matching rules stay yours. Functions, which are generally available, run single-purpose TypeScript or JavaScript on Sanity's infrastructure in response to document `create`, `update`, and `delete` events. A function can read and write the dataset, traverse references, and call external services, which is enough to compare an incoming record against existing documents, flag a probable duplicate for review, or call out to a dedicated resolution service and write the result back. That is the Automate everything pillar in practice.
For the candidate-generation part of the problem, dataset embeddings let a GROQ query rank records by meaning using `text::semanticSimilarity()`. Two limits matter. Semantic similarity is only valid inside `score()`, so it ranks rather than filters; narrow the candidate set with a real filter first, then rank. And `_score` is an opaque, unitless value that is meaningful only for ordering within a single query, so do not compare scores across queries or set a fixed threshold against them. For scale beyond a content repository, the reference implementation to read is Splink, the UK Ministry of Justice's open-source probabilistic record linkage library built on the Fellegi-Sunter model, which GOV.UK describes running linkage on datasets of around 15 million records.
Explore Sanity Today
Understanding entity resolution is just the beginning. Take the next step and discover how Sanity can enhance your content management and delivery.
Last updated: