What an Entity Resolution Rollout Actually Looks Like in 2026, End to End

TL;DR: A production entity resolution rollout is a controlled sequence: define the decision, choose two useful sources, prepare and normalise records, tune against labelled truth, choose the deployment perimeter, run in parallel, then monitor both accuracy and operations. The matching algorithm is one phase. Ownership, review and cutover determine whether the system is trusted.

Prove the configuration before cutover. Walk through the rollout with our team or test match behaviour locally on a controlled extract. Book a Demo or Try Tilores Studio (Free).

On this page

What are the rollout phases?
How do you scope sources?
What happens in normalisation?
How do you tune matching?
How do you choose deployment?
What does cutover look like?
What do you monitor?
Frequently asked questions

Entity resolution implementations rarely fail because nobody can compare two names. They fail because the team has not agreed which business decision needs a resolved entity, who owns an uncertain match, or how a new identity will reach the systems that need it.

A credible rollout therefore begins outside the algorithm. It defines a narrow decision, builds a truth set from the records that make that decision difficult, proves the matching behaviour and promotes the same evidence into production. The deployment and cutover are part of the matching design because they determine how current, traceable and reversible the result will be.

This is the end-to-end runbook we use in 2026. Managed Cloud on AWS is the default production track. Your AWS Account, Another Cloud and On-Premise are deliberate branch points when the data perimeter or operating model requires them.

What are the phases of an entity resolution rollout?

A rollout has seven phases with an evidence gate between each one.

Decision and ownership. Define what the resolved entity will change and who accepts match risk.
Source scope. Select the first records, fields and update paths.
Preparation and normalisation. Map values while retaining source lineage and originals.
Match configuration and truth. Separate deterministic, fuzzy and probabilistic methods and measure them against labelled cases.
Deployment and integration. Place the engine at the approved perimeter and connect GraphQL consumers.
Parallel run and cutover. Compare the new entity with the existing process before changing decisions.
Operations and improvement. Monitor accuracy, freshness, lineage, access and deletion after go-live.

Each gate produces evidence the next team can inspect: a scope and risk statement, source contract, reproducible mappings, labelled fixtures, approved architecture, reconciliation report, and owned operations dashboard.

Do not allow a presentation, a clean sample or an aggregate accuracy number to substitute for these artefacts. The work advances when the next team can inspect and use the result.

How do you scope the first data sources?

Choose the first sources by decision value and identity contrast, not by volume. Two sources that describe the same customer differently will teach the team more than ten tables copied from one system.

A practical first scope might pair CRM contacts with support customers or merchants with screening records. One source should contain a trusted identifier; the other, the variation causing the business problem. Avoid the whole enterprise model.

Write the target decision in operational language. “Create a customer 360” is too broad. “Show a support agent the authenticated caller’s open orders” and “prevent one legal entity entering sanctions review under two spellings” are testable.

For every source, document:

the source owner and authoritative record ID;
how creates, updates and deletions are delivered;
which attributes may contribute to identity;
which values are verified, declared or inferred;
expected freshness and peak arrival rate;
retention and residency constraints;
downstream consumers allowed to see the source;
the procedure for correcting a bad record.

Profile the data before writing rules. Count missing values, reused identifiers, impossible dates, shared addresses and country-specific formats. Sample common and rare values. A telephone number that appears on one thousand records is not the same signal as a verified number unique to one account.

Create the first truth set during source discovery. Ask subject-matter owners for known duplicates, non-matches and review cases, including changed names, addresses and reassigned identifiers. These become regression tests.

In financial services, scope the screening decision explicitly. Resolution can help connect aliases and customer records before sanctions, politically exposed person and adverse media checks. OpenSanctions is a useful open data source for testing name variation, but the screening policy and final decision remain separate from entity resolution.

What happens in the ETL and normalisation step?

The preparation phase establishes a stable source envelope before it changes the values used for comparison. Every record should arrive with a source name, source record ID, event or update time and an operation. Keep the original values.

Normalisation makes comparable values easier to compare. It may standardise case, whitespace, Unicode, telephone country codes, address components and common date forms. It does not mean erasing the original spelling or forcing every jurisdiction into one format.

Tilores normalises and persists ingested data while retaining originals. This distinction matters in review. An investigator may need to see that “Müller” arrived with the umlaut even if the comparison also considered a transliterated form. An engineer needs to know whether an apparent mismatch came from the source or a normalisation rule.

Separate source-specific transformation from matching logic. If one legacy system stores surname and given name in a single reversed field, correct that mapping in the ingestion layer. If several sources need tolerant comparison of name order, keep the behaviour in the match configuration. That division makes errors easier to locate.

Test the data contract with late, repeated and deleted events. A retried update must be idempotent. A deletion must remove or reorganise the relevant record in the entity. A late correction must not silently restore stale data. Track event time and processing time separately.

The output of this phase is not a clean table. It is a reproducible pipeline with lineage. A reviewer can select any record in a resolved entity and identify where it came from, what changed, which original value was retained and when the current state was produced.

Phase	Exit evidence	Accountable owner
Decision and ownership	Defined business action, harm model and escalation path	Business owner
Source scope	Source contracts, deletion paths and permitted fields	Source owners
Preparation	Reproducible mappings, lineage and data-quality findings	Data engineering
Match tuning	Held-out truth set, thresholds and error ledger	Data science plus business reviewer
Deployment	Approved perimeter, GraphQL integration and recovery design	Platform and security
Parallel run	Risk-weighted reconciliation and signed exit criteria	Programme owner
Operations	Alerts, review queue, change control and repair test	Service owner

How do you tune matching before you trust auto-merge?

Start with the highest-confidence evidence and expand only when observed errors justify it.

Deterministic matching uses exact trusted identifiers or exact combinations. Fuzzy matching compares close but non-identical values such as spelling variations. Probabilistic matching combines several signals and their relative rarity into a likelihood or score. These methods complement one another and should not be collapsed into a single vague claim about artificial intelligence.

The classical Fellegi-Sunter framework remains useful because it makes link evidence explicit. Modern implementations are faster and more operational, but the discipline survives: estimate how strongly agreements and disagreements distinguish matches from non-matches.

The US Census Bureau’s current review of Fellegi-Sunter methods places the model in a broader latent-class framework, while its earlier frequency-based matching research shows why the frequency of an agreeing value changes its evidential weight. That is the practical reason a shared common surname should not count like a rare verified identifier.

Use separate labelled sets for tuning and evaluation. If the team adjusts rules until every example passes and then reports performance on those same examples, it has measured memory rather than generalisation.

Measure pair precision and recall, then inspect entity-level errors. A false link between two large clusters can be more damaging than several missed pairs. Track:

false merge rate;
missed link rate;
unexpectedly large or fast-growing entities;
split entities that share a trusted identifier;
review volume by rule and source;
performance by country, script and source system;
stability when new records arrive or old records are removed.

Define three outcomes rather than forcing a binary answer. High-confidence cases may auto-merge. Clear non-matches remain separate. An uncertain middle enters review. The width of that middle depends on business harm. A customer marketing use case can accept different trade-offs from a decision that may expose financial or health data.

Reviewers need a consistent interface and reason codes. Capture why they accepted or rejected a link, then sample those decisions for quality. Do not turn every individual choice into a rule automatically. A repeated pattern can justify a configuration change after it is tested against the full regression set.

Before the auto-merge gate opens, the accountable business owner should sign the thresholds and error budget. The data team can describe performance. The business must own the consequence of a false merge or missed link.

How do you choose your deployment model, and when?

Choose the provisional deployment perimeter during source scope and confirm it before production integration. Leaving the decision until the end often forces the team to repeat security, networking and performance work.

The four Tilores deployment models are:

Managed Cloud on AWS. The default and shortest supported production path.
Your AWS Account. For AWS account control or residency requirements.
Another Cloud. An approved non-AWS cloud with the same application contract.
On-Premise. A local or isolated perimeter where cloud is not permitted.

Underneath the engine are a key-value store, a queue and file storage. The AWS reference uses DynamoDB, SQS and S3. This limited set of primitives makes the placement decision easier to reason about and supports isolated or air-gapped environments without presenting them as the default.

Assess data movement, operational ownership, availability, recovery, expected ingestion, query latency and network path. Record which team patches and monitors the surrounding infrastructure for each self-managed model. The GraphQL API remains the route for production reads and writes.

Use Tilores Studio before this gate when a local data evaluation is the safest starting point. Studio runs the full engine locally on up to 100,000 records. It proves configuration and match quality. It does not replace the production architecture.

The signed architecture should link to the deployment model rather than copying a transient product description into every project document.

What does cutover and parallel running look like?

Do not cut over by replacing every customer ID on one date. Introduce the new entity beside the existing view and compare them at the decision boundary.

Start with shadow writes or a bounded backfill. Expose the resolved entity to a validation application while existing systems remain authoritative and reviewers inspect disagreements.

Reconcile four classes:

Both systems agree on the entity.
The new system links records the old view kept apart.
The old view links records the new system keeps apart.
One system lacks the record or is stale.

Sample each class by risk, not just by count. A disagreement involving a common email domain and no other evidence deserves different treatment from one involving a verified account identifier.

Then cut over one reversible consumer. Confirm access controls, latency, error handling and fallbacks. Where a wrong identity could expose data, applications should fail closed rather than guess from a partial GraphQL result.

Publish a stable entity ID contract. Explain what happens when entities merge, split or change after deletion. Downstream teams need a mapping or event trail so they can preserve history. Avoid forcing every consumer to reimplement identity state changes.

Set exit criteria before the parallel run begins. They should include match-quality thresholds, operational availability, freshness, reconciliation completion, review backlog and business acceptance. A calendar date alone is not an exit criterion.

What do you monitor after go-live?

Production monitoring covers data, identity, service and governance.

Data monitoring checks source arrival, schema drift, missing fields, duplicate event IDs and deletion completion. Identity monitoring checks false-merge samples, missed-link samples, cluster growth, rule contribution and review outcomes. Service monitoring checks ingestion lag, GraphQL latency, queue depth, errors and availability. Governance monitoring checks access, exports, retention actions and unusual query patterns.

Create alerts for changes in the evidence distribution, not only infrastructure failures. If a source that usually provides verified emails suddenly sends blanks, the queue may be healthy while match quality deteriorates. If one rule begins creating much larger entities, stop or review it before errors spread.

Maintain a small permanent truth set and a rotating sample from current production. The permanent set catches regressions. The rotating set catches new behaviour, new source systems and demographic or jurisdictional blind spots.

Hold a regular error review with engineering and the business owner. Decide whether each false merge, missed link or uncertain case needs a source fix, mapping change, threshold change or permanent review. Version every change and rerun regression tests.

Finally, test reversibility. Confirm that a bad source batch can be identified, that records can be corrected or deleted, and that entities reorganise accordingly. A resolution system earns trust when the team can explain and repair a decision, not when it claims never to be wrong.

Frequently Asked Questions

How long does an entity resolution implementation take?

An entity resolution implementation should be planned by evidence gates rather than a universal duration. A narrow two-source rollout moves faster than an enterprise cutover, but both still need source contracts, labelled truth, deployment approval, parallel running and operational ownership.

Which sources should an entity resolution rollout start with?

An entity resolution rollout should start with two sources that matter to one operational decision and describe the same subject differently. Starting with the whole enterprise model slows learning and obscures risk.

How should matching thresholds be approved?

Matching thresholds should be tested on held-out labelled cases and approved against the harm of false merges, missed links and manual review. The accountable business owner signs the error budget, not the algorithm alone.

When should a team choose the deployment model?

The team should choose a provisional deployment model during source scoping and confirm it before production integration. Data movement, residency, operating ownership and network path can otherwise force expensive rework.

What should be monitored after go-live?

After go-live, monitor source freshness, schema drift, false merges, missed links, entity growth, review outcomes, GraphQL performance, deletion completion and configuration changes.