How to Design an Identity Graph That Stays Accurate: 6 Architecture Decisions for 2026
TL;DR: An identity graph goes stale when its keys, edges, and clusters cannot absorb new records without a full rebuild. Six decisions keep it accurate as data changes in 2026: stable entity keys, weighted edges, provenance on every edge, versioned merges and splits, incremental re-matching, and drift monitoring. A 110-million-record production graph shows what happens when all six hold.
Design the graph before the data forces the issue. Walk the architecture through with our team, or test the matching behaviour on your own records first. Book a Demo or Try Tilores Studio (Free).
On this page
- What makes an identity graph go stale in the first place?
- Decision 1: Choose entity keys that outlive any one source system
- Decision 2: Give every edge a confidence score, not just a boolean link
- Decision 3: Record provenance on every edge
- Decision 4: Version merges and splits so they can be replayed
- Decision 5: Re-match incrementally instead of rebuilding the graph
- Decision 6: Monitor for drift before it compounds
What makes an identity graph go stale in the first place?
An identity graph does not go stale because the data changes. Data always changes: names get transliterated differently, companies merge, phone formats vary by system. It goes stale when the graph’s structure cannot absorb that change without a full rebuild, so accuracy quietly decays between rebuilds instead of holding steady.
Record linkage as a discipline is older than any graph database. William Winkler’s 2006 US Census Bureau research report frames the core task plainly: comparing name and address information across pairs of files “to determine those pairs of records that are associated with the same entity,” with the most sophisticated approaches using “graph theoretic ideas for representing linkage relationships as conditional random fields that be partitioned into clusters representing individual entities.” That is the identity graph, described sixty years into the field’s history: nodes are records, edges are match decisions, clusters are resolved entities.
Neo4j’s own guidance on graph modelling adds the part that matters for staying accurate over time: “creating a model is an iterative process,” refined through testing as data requirements and query patterns become clearer. A graph designed once and left alone is a graph designed for the data you had on day one, not the data arriving in year two. Six decisions determine whether it can keep up, and a production graph resolving company identity across more than 16 source systems shows what each one looks like once real, messy data is running through it.
Decision 1: Choose entity keys that outlive any one source system
Neo4j’s guidance on node modelling is a useful starting discipline even outside a graph database: “the dominant nouns in your application use case are represented as nodes,” each needing a “unique identifier” enforced so “every node is a separate and distinguished entity.” The trap in identity resolution is picking a source system’s primary key as that identifier. A CRM ID, an ERP customer number, or a support-ticket account ID all describe the same real person or company differently, and none of them survives a system migration.
An entity key needs to be assigned by the resolution layer itself, at the point a cluster first forms, and it needs to stay stable even when every source record behind it later changes. Tilores assigns this at the entity level, independent of any source system’s own numbering, precisely so a migration or a new integration does not force every downstream system to re-key its records. That independence is what lets a graph span sources as different as a clean legal-entity registry and a scanned customs form, the range one due diligence platform resolves into a single company graph today.
A graph stays accurate when every link carries the evidence needed to update, explain, reverse and monitor it.
Decision 2: Give every edge a confidence score, not just a boolean link
A graph that only records “these two records match” or “they do not” throws away the information a steward or an engineer needs later to decide whether a borderline match should be revisited. The Tilores API returns two distinct scores on every match: an entity score, “the overall quality of matches within the entity,” and a hit score, “how closely the match aligns with the provided search parameter,” both floats in the range zero to one.
Storing that score on the edge itself, not just as a side output of the matching run, means a later query can ask for every cluster whose weakest edge falls below a threshold, which is exactly the set of clusters worth a manual review before they compound into a larger error. Scored edges also keep queries fast at scale: a graph holding 60 million resolved company clusters can still answer a lookup in around 100 milliseconds, because the score travels with the edge rather than being recomputed on read.
Decision 3: Record provenance on every edge
Neo4j’s modelling guidance notes that “properties for a relationship are used to enrich how two nodes are related,” used when you need to know how two nodes connect and not just that they do. Provenance is the relationship property that matters most for an identity graph: which source record, which matching rule or model version, and which run produced this edge.
Without it, explaining a merge months later means re-running the match from scratch and hoping the result is reproducible. With it, a data steward or a regulator can open the exact edge, see the rule that fired and the record pair it compared, and get an answer immediately. A graph built on 23 clustering rules tuned jointly against a ground-truth dataset only stays explainable if every edge records which of those 23 rules fired. Tilores’ Record Insights layer exposes this directly: filtering, statistics, and aggregation across the records inside a resolved entity, so the “why” behind a cluster is queryable rather than reconstructed after the fact.
Decision 4: Version merges and splits so they can be replayed
Every identity graph eventually gets a merge wrong, usually because two source records genuinely looked like the same entity at the time and later evidence showed they were not. A graph without versioning treats that correction as a destructive edit: the old state is gone, and there is no way to show what the graph believed before the fix.
A versioned graph treats a merge or split as an event with a before-state and an after-state, both queryable. That makes an incorrect merge reversible without cascading damage to everything that referenced the old cluster, and it gives an auditor a real answer to “what did this record look like on the date in question,” rather than only “what it looks like now.”
Decision 5: Re-match incrementally instead of rebuilding the graph
AWS’s own entity resolution service distinguishes two processing modes: “manual bulk processing,” which reprocesses an entire dataset on demand, and “automatic incremental processing,” which compares only new records against the existing set as data arrives. The difference compounds at scale. A graph that can only be rematched by reprocessing everything either runs infrequently, so it lags behind incoming data, or runs constantly, at a cost that grows with total graph size rather than with the size of what actually changed.
Designing for incremental matching from the start, so a new record is compared against existing clusters rather than triggering a full recompute, is what makes real-time resolution possible without an ever-growing batch window standing behind it. It is also what makes a large initial load practical in the first place: a full first pass over more than 100 million source records can complete in under a day precisely because every record after that first load only needs to be compared against the graph once, not reprocessed alongside everything already resolved.
Decision 6: Monitor for drift before it compounds
A graph that was accurate at launch degrades quietly as source data shifts underneath it: a new upstream system starts sending a name field formatted differently, or a data provider changes an encoding, and match rate falls before anyone notices. The fix is not a one-time accuracy test at go-live. It is a standing check on cluster size distribution, match rate against a rolling baseline, and the share of matches sitting close to the confidence threshold rather than clearly above or below it.
Measured this way, the payoff is concrete rather than theoretical: moving from an address-dependent matching approach to one built around the six decisions above turned a documented weakness, low recall against messy source data, into a 30-point F1 improvement over the previous approach on the same ground-truth dataset. That is a large enough topic to deserve its own answer, covered in a companion piece on explainable entity resolution and confidence-threshold auditing. A graph designed with edge scores, provenance, and versioning already carries the data a monitoring pass needs; a graph without them has to reconstruct that evidence from scratch every time something looks wrong.
| Decision | What goes wrong without it | What it enables |
|---|---|---|
| 1. Stable entity keys | Every source migration forces a re-key across all downstream systems | An entity ID that survives a CRM or MDM migration |
| 2. Edge confidence scores | No way to find weak matches before they compound | Queryable review of every cluster below a threshold |
| 3. Edge provenance | A merge can only be explained by re-running the match from scratch | Immediate, reproducible answers for a steward or regulator |
| 4. Versioned merges and splits | A correction destroys the record of what the graph believed before | Reversible corrections and a real point-in-time answer |
| 5. Incremental re-matching | Cost and lag both grow with total graph size, not with what changed | Real-time resolution without an ever-growing batch window |
| 6. Drift monitoring | Accuracy decays quietly between rebuilds with no visible signal | An early warning before a shift in upstream data becomes a large error |
None of this is unusual for the underlying problem, only for how rarely a graph is designed to expect it. A name that carries extraneous tokens, or part of an address embedded inside it, defeats an ordinary fuzzy or exact search outright, which is exactly why the six decisions above are structural rather than optional once new, messier sources keep joining the graph. Applied consistently, they are what let a graph absorb its hundredth new source the same way it absorbed its first: without a rebuild, and without a quiet decline in what it can be trusted to answer.
FAQ
What is an identity graph in entity resolution?
An identity graph represents records as nodes and match decisions as edges, with clusters of connected nodes representing a single resolved real-world entity. It is the structural form that record linkage research has used for decades, applied to a live, continuously updated dataset.
Why does an identity graph need versioning?
Without versioning, correcting an incorrect merge is a destructive edit that erases what the graph believed before the fix. With versioning, a merge or split is an event with a before-state and after-state, so a mistake can be reversed and an auditor can see what a record looked like on a given date.
What is the difference between bulk and incremental matching?
Bulk processing reprocesses an entire dataset on demand, which works but grows more expensive as the dataset grows. Incremental processing compares only new or changed records against the existing set as data arrives, which is what makes real-time resolution practical at scale.
How many source systems can one identity graph resolve?
There is no fixed limit, but the difficulty scales with how inconsistent the sources are, not just how many there are. Exiger resolves more than 16 distinct sources, ranging from clean legal-entity registries to global customs and shipping data, into one entity graph.
What should a team monitor to catch identity graph drift early?
Match rate against a rolling baseline, the distribution of cluster sizes, and the share of matches sitting close to the confidence threshold rather than clearly above or below it. A graph designed with edge-level confidence scores and provenance already carries the data this monitoring needs.
Sources
- Overview of Record Linkage and Current Research Directions, William E. Winkler, US Census Bureau, checked 2026-08-26.
- Graph Data Modeling Guidelines, Neo4j Developer Guides, checked 2026-08-26.
- What Is AWS Entity Resolution?, AWS Entity Resolution Documentation, checked 2026-08-26.
- API Reference, Tilores Documentation, checked 2026-08-26.
- Exiger Case Study: Resolving the World’s Companies at Scale, Tilores, checked 2026-08-26.
- Deployment Options: Run Tilores Where Your Data Is, Tilores, checked 2026-08-26.
- Explainable Entity Resolution: Confidence Thresholds and Audit, Tilores, checked 2026-08-26.
- Contact, Tilores, checked 2026-08-26.
See what resolved entity data does for your business — and your AI.