Run Entity Resolution on Your Own Machine First: A Developer’s Ten-Minute Evaluation

TL;DR: A useful entity resolution evaluation should run against your own difficult records, on your own machine, before a sales conversation. Tilores Studio runs the full engine locally on up to 100,000 records. Use the first ten minutes to prove the path, then spend the real evaluation time measuring false merges, missed links and the operational route to production.

Test the engine on your data. Run a private local evaluation or talk through the production path with our team. Book a Demo or Try Tilores Studio (Free).

On this page

What can you test before talking to a vendor?
How do you run the engine locally?
What does the engine need?
How do you benchmark match quality?
When do you outgrow a local library?
How do you move to managed AWS?
Frequently asked questions

An entity resolution demo becomes useful at the moment the vendor stops controlling the data. Clean sample rows can prove that a screen works. They cannot tell you whether two misspelt names, a recycled telephone number and an old address belong to one customer in your environment.

That is why the first evaluation should happen on your machine. Start with a deliberately small extract that contains real duplicates and real ambiguity. Keep the data local. Get a first result quickly. Then use the rest of the exercise to answer the question that matters: are the resolved entities accurate enough to support a production decision?

Tilores Studio is built for that sequence. It runs the full Tilores engine locally, accepts up to 100,000 records and does not require signup or a licence key. A prepared CSV can produce the first matched entities in under ten minutes. That is the beginning of the test, not the conclusion.

What can you actually test before talking to a vendor?

You can test match behaviour, configuration fit and output usefulness without first granting a vendor access to customer data. A good local evaluation should answer five concrete questions.

First, can the engine link the records your team already knows belong together? These are the obvious duplicates: a stable account number, the same normalised email, or a trusted external identifier. They establish that the ingestion and deterministic rules are sound.

Second, can it handle the records that differ for ordinary human reasons? Names are transliterated, addresses are reformatted, telephone numbers gain or lose a country code, and people mistype an email. Fuzzy matching deals with close but non-identical values. It should remain separate from probabilistic matching, which weighs several partial signals to estimate whether a link is credible.

Third, can it resist a tempting but wrong merge? A shared household address, family telephone number or common surname can make two people look similar. These negative examples are often more valuable than the easy positive ones because a false merge can disclose one customer’s data to another.

Fourth, does the resolved output carry the evidence a downstream team needs? An entity ID is useful, but engineers should also be able to inspect the source records, original values, normalised values and the reason a link was made. Tilores normalises and persists the ingested data while retaining originals, so a reviewer can see both what arrived and what was compared.

Fifth, can the evaluation become a production design without starting again? A laptop proves matching behaviour. It does not prove ingestion throughput, availability, access control or operating cost. The evaluation should therefore capture a configuration and a labelled test set that can travel into the production phase.

Open source tools remain useful here. Splink is strong for probabilistic linkage and analytical work. dedupe provides active learning for record linkage in Python. Zingg supports scalable entity resolution workflows. AWS Entity Resolution provides a managed route inside the AWS ecosystem. The point of a local evaluation is not to produce another feature matrix. It is to run the contenders against the same hard records and the same acceptance criteria.

How do you run the full resolution engine on a laptop with no data leaving it?

Start by creating an evaluation extract rather than copying a production table wholesale. Include a stable source record ID, the attributes you may match on and enough source metadata to trace every row. Remove columns that have no bearing on identity. The exercise is easier to govern and easier to debug when every field has a purpose.

Aim for three groups of examples:

Confirmed links that should resolve to one entity.
Confirmed non-links that must remain separate.
Uncertain cases that require a reviewer rather than an assumed answer.

The third group matters. A benchmark that labels every ambiguous pair as correct or incorrect creates false confidence. Keep an explicit review state for cases where the business does not yet know the truth.

Download Tilores Studio, open the local application and load the prepared data. The records and matching process remain on the machine. Map the source columns to the relevant identity attributes, then begin with the most defensible rules. A trusted customer ID may be deterministic. A normalised email can be deterministic when the source guarantees ownership. A name and address usually need more care.

For the first pass, resist the urge to encode every exception the team has ever seen. Run a small configuration, inspect its clusters and save the errors. Add complexity only when an observed failure justifies it. This keeps each rule explainable and prevents a broad fuzzy rule from hiding behind a good aggregate score.

The ten-minute target is deliberately narrow. With a clean extract, it is enough time to install Studio, load data and see the first resolved entities. It is not enough to validate match quality. Budget a separate session for error analysis with the people who understand the source data.

If policy prevents any customer extract from reaching a developer laptop, use synthetic records shaped like the real schema. Preserve the patterns without preserving the people: missing fields, transliteration, shared contact details, stale addresses and source-specific formatting. Later, repeat the accepted configuration inside an approved environment against controlled data.

What does the engine actually need underneath it?

Production entity resolution sounds like a large platform because many products arrive with a large platform attached. The core Tilores engine needs three infrastructure primitives: a key-value store, a queue and file storage. On AWS the reference implementation uses DynamoDB, SQS and S3.

The key-value store holds the current operational state needed to find and update entities. The queue lets ingestion and resolution work proceed reliably as records arrive. File storage carries durable objects such as imports and exports. There is no fourth hidden database or separate search cluster to introduce into the architecture.

That small dependency surface is important after the laptop test. It lets the same resolution behaviour run in Managed Cloud on AWS, in your AWS account, in another cloud or on-premise. The default path for most teams is Managed Cloud on AWS because it removes the operating work while preserving a clear route to a different perimeter when policy requires one.

Production applications read and write through one GraphQL API. They are not expected to reproduce the matching logic in Python notebooks or copy clusters into a new service. The local evaluation is therefore a way to validate the engine and configuration, not a commitment to operate a desktop tool in production.

How do you benchmark match quality on your own records?

Begin with a labelled truth set that is small enough to inspect. Random pairs are a poor truth set because almost every possible pair in a customer database is a non-match. Include difficult positive links and difficult negative links on purpose.

At pair level, precision asks what proportion of predicted links are correct. Recall asks what proportion of true links the engine found. Both matter, but they have different consequences. Low precision creates false merges. Low recall leaves duplicates apart. A fraud, compliance or customer-service use case may put a much higher cost on a false merge than a missed link.

The statistical basis is not new or proprietary. The US Census Bureau’s work on the Fellegi-Sunter model explains why agreements on rare values carry different evidence from agreements on common ones. Its three-way decision pattern of link, possible link and non-link is still a useful way to design a review band rather than forcing every pair into a binary answer.

The ONS data-linkage policy is unusually direct on evaluation: match rate alone says nothing about linkage quality, so precision and recall should be reported and error or bias should be examined for hard-to-match populations. The UK government’s quality-assessment guidance adds a third requirement: inspect how errors affect clusters and the downstream variables that matter to the analysis.

Pair metrics do not tell the whole story. Entity resolution creates clusters, so inspect cluster-level failures too. One wrong bridge can combine two otherwise correct groups. Conversely, one missed bridge can split a single customer’s history across two entities. Track at least:

false merge rate for labelled non-links;
missed link rate for labelled links;
number and size of unexpectedly large clusters;
proportion of records sent to manual review;
stability of entity IDs when a new record arrives;
time from ingestion to a current resolved entity.

Review errors by source and attribute. If nearly every false merge comes from a reused household telephone number, the remedy is not a global threshold change. It may be a source-specific rule or a lower weight for that field. If transliterated names generate missed links only in one jurisdiction, improve the normalisation for that source rather than loosening all name comparisons.

Keep the labelled rows and the expected outcomes in version control without customer values. They become regression fixtures. Every configuration change should rerun the same cases so a gain in one segment does not silently damage another.

Finally, measure operational behaviour separately from accuracy. Load a representative burst, observe the current entity through GraphQL and record how the system behaves when the same source record is corrected or deleted. Match quality can be excellent while the update path remains unsuitable for a real-time application.

When do you outgrow a local library in production?

You outgrow a local approach when the job stops being a periodic analysis and becomes shared operational infrastructure.

A Python library can be the right answer for a bounded batch, especially when a data scientist owns both the model and the output. It becomes harder when several applications need the same current entity, new records arrive continuously, users need predictable GraphQL access, and compliance teams require a durable record of queries, changes and deletions.

The warning signs are familiar. Each team starts exporting its own clusters. Stable entity IDs change between runs. Matching code lives in a notebook owned by one person. A nightly batch becomes a four-hour critical path. Downstream services cannot tell whether the current profile includes the latest support or payment event. Review decisions never make it back into the configuration.

That does not make an open source library inferior. It means the operating requirement has changed. Keep the benchmark that proved the matching logic, then evaluate the production layer on ingestion, current-state queries, lineage, access control, deletion and deployment fit.

How do you move from a local test to managed AWS?

Treat the move as a promotion of evidence, not a rewrite. Carry forward the source mapping, matching configuration, labelled fixtures and acceptance thresholds. Re-run the same truth set in the target environment before connecting a downstream application.

For most teams, the first production choice is Managed Cloud on AWS. It gives the team a supported service while the application continues to use the GraphQL interface tested during evaluation. If infrastructure must remain under your control, the next model is Your AWS Account. Another Cloud and On-Premise cover perimeters that cannot use the first two options.

Promote one source first. Ingest it, verify entity stability and observe updates. Add the second source only when its ownership, deletion path and match contribution are understood. During cutover, compare the new resolved entity with the existing customer view rather than immediately replacing it. Disagreements are test cases, not annoyances.

The result of a successful evaluation is not a perfect match score on a clean sample. It is an evidence pack that says where the engine is right, where it is uncertain, how errors will be reviewed and how the same behaviour will operate at the required perimeter. A laptop can give you the first answer in ten minutes. The disciplined work that follows is what makes the answer safe to use.

Evaluation question	Evidence to keep	Production consequence
Can the engine link difficult true matches?	Labelled positive pairs and missed-link review	Recall target and review workload
Can it keep similar people or companies apart?	Labelled negative pairs and false-merge review	Precision target and auto-merge boundary
Does a correction change the right entity?	Before-and-after record, entity ID and match evidence	Update, split and repair procedure
Does a deletion reorganise the entity?	Deletion event and resulting entity membership	Retention and erasure runbook
Can applications use the current result?	GraphQL query, latency and failure test	Integration and fallback design

Frequently Asked Questions

Can I test Tilores without sending data to the cloud?

Tilores Studio runs the full entity resolution engine locally, so a controlled evaluation can stay on the evaluator’s machine. Use synthetic records when policy does not allow even a local customer extract.

How many records can Tilores Studio evaluate?

Tilores Studio supports up to 100,000 records in local mode. That is enough for a meaningful proof of concept, but the sample still needs deliberate difficult matches and non-matches.

What should an entity resolution benchmark measure?

An entity resolution benchmark should measure precision, recall, false merges, missed links, review volume, cluster-level errors, entity-ID stability and update behaviour. One aggregate accuracy number is not enough.

When should a local evaluation move to production?

A local evaluation should move to production only after the source mapping, labelled fixtures, thresholds, review policy, deletion path and application contract have all been proved and assigned to owners.

Does the production integration use REST?

Tilores uses GraphQL for production reads and writes. The local evaluation and production deployment keep the same application contract.