Every few years, the entity resolution space produces a new framing that repackages familiar ideas in more compelling language. Entity centric matching is the current favourite. The premise sounds compelling: instead of comparing pairs of records, you compare each incoming record against a holistic, accumulated entity profile, one that grows smarter over time as more data arrives.
It is a genuine step beyond the most naïve record-to-record approaches. But the claims made on its behalf have quietly expanded well beyond what the architecture actually delivers. If your organisation is evaluating entity resolution tooling, or building a data platform that will need to scale, this distinction matters.
The question is not whether entity centric matching is useful. It is whether it is the right foundation for systems that must be accurate, auditable, and truly scalable.
An entity centric system maintains a resolved entity store, a collection of profile objects, each representing a real-world entity as understood from the data seen so far. When a new record arrives, it is compared against these profiles rather than against every other raw record. If a match is found, the record is merged into the profile, expanding it. If not, a new profile is created.
The result is a continuously updated entity store that accumulates attribute variations over time: alternative names, known addresses, observed identifiers. Proponents describe this as learning. The system gets smarter as it sees more data. Self-correction is possible when new evidence contradicts an earlier decision.
This is useful. It is also more limited than the framing suggests, and in several ways that become apparent at scale.
Retaining attribute variations per entity at runtime is not model-level learning. The matching logic, its weights, thresholds, and similarity decisions, is fixed. It was set before your data arrived. What changes over time is the profile being matched against, not the intelligence doing the matching. These are fundamentally different things, and conflating them overstates what the system is actually doing.
Entity centric systems arrive pre-trained, with matching logic calibrated for broad, generic applicability. Your data has its own characteristics: industry-specific abbreviations, regional name conventions, data quality patterns unique to your sources and ingestion pipelines. A pre-trained engine applies its priors to your data. A model trained on your data learns from it. These produce meaningfully different matching behaviour, particularly at the margins where most errors live.
When matching is anchored to an accumulated entity profile, early errors compound. An incorrect merge early in ingestion creates a corrupted profile that becomes the reference point for all subsequent matching decisions. Self-correction is possible in principle, but requires contradictory evidence strong enough to overcome accumulated profile weight. Subtle, persistent errors, the kind most likely to matter in fraud detection or compliance contexts, are exactly the kind that do not trigger self-correction.
Entity centric matching systems are typically proprietary. When a match is made or rejected, the reasoning is embedded in a profile-comparison engine that cannot be externally inspected. In regulated industries, financial services, healthcare, public sector, explainability is not a preference. You need to demonstrate why a match was made, traceable to inspectable logic and labelled data, not to a profile accumulator whose internals are not available for review.
As the number of resolved entities grows, so does the cost of comparing each incoming record against the full entity store. This architecture was designed for streaming ingestion at moderate volumes. It was not designed for bulk resolution of hundreds of millions of records across distributed compute infrastructure, the workloads that characterise modern data platforms built on Spark, Databricks, or cloud data warehouses.
Zingg builds its matching model from labelled examples drawn from your actual data. With as few as 30–40 annotated pairs, Zingg learns the similarity thresholds and attribute weights that reflect your matching logic, not a vendor’s assumptions about what matching generally looks like. The model is a direct expression of the evidence in your data.
Zingg first learns a blocking model that indexes near-similar records into clusters, dramatically reducing the comparison space before similarity scoring begins. Typical Zingg comparisons reach just 0.05–1% of the full pairwise problem space. This makes bulk entity resolution viable at scale on distributed compute platforms, Spark, Databricks, AWS Glue, without architectural compromise.
Because Zingg is open source and the models are trained artifacts, every matching decision is traceable to the training data and model logic behind it. You can inspect what the model learned, review the labelled pairs that shaped it, and explain any match or non-match to a regulator, auditor, or business stakeholder. There is no black box, there is a model you built and can examine.
Zingg allows you to define custom similarity functions for the specific fields and data types in your domain, going beyond generic string similarity to capture the semantics of how your data actually varies. Legal entity names, product identifiers, address formats, and domain-specific codes all match differently. Zingg lets you encode that knowledge explicitly.
Zingg runs where your data already lives. There is no proprietary entity store to feed, no data leaving your environment, no external ingestion pipeline to maintain. Models are persisted and applied to new and incremental datasets without retraining from scratch, giving you a continuous resolution pipeline that integrates cleanly with the rest of your data platform.
Entity centric matching is a runtime strategy: accumulate more about known entities over time, and use that accumulated knowledge to match new records against what you have collected. It is reactive. The intelligence lives in a growing profile store.
Zingg is a learning strategy: build a model from labelled evidence in your actual data, and apply that model consistently, transparently, and at scale. The intelligence lives in the model, one you built, one you understand, and one that reflects the genuine structure of your matching problem.
For straightforward identity resolution on clean, well-structured data at modest volume, entity centric matching may be sufficient. But for organisations operating at scale, in regulated environments, on complex or messy data, or on cloud-native data infrastructure, the architectural differences are not marginal. They determine whether your entity resolution layer is a trusted component of your data platform, or a difficult-to-audit dependency you work around.
The question worth asking of any entity resolution system is not how impressively its capabilities are described. It is whether you understand what it is doing, whether you can verify it, and whether it will hold up when your data, your scale, or your compliance requirements demand more than it was designed to give.
.png)
