How to Handle Entity Merges, Splits and Stable IDs Downstream (2026)

TL;DR: Never make downstream correctness depend on an entity ID never changing. Keep immutable source-record IDs, maintain canonical and alias mappings, emit idempotent merge and split events, and let consumers resolve references through an identity boundary. Preserve the old-to-new lineage and effective time. We keep IDs stable where possible, but merges, splits and deletion can change them, so consumers must implement those lifecycle events explicitly.

Test your matching configuration on a controlled data extract. Book a Demo · Try Tilores Studio (Free).

On this page

1. Why can an entity ID change?
2. How should record, entity and business identities be separated?
3. Treat merges and splits as a public event contract
4. A downstream implementation checklist
5. Three failure modes to test before release
6. What evidence keeps an entity change reversible?
7. How do entity changes behave in Tilores?
8. FAQ
9. Sources

Why can an entity ID change?

An entity is a conclusion drawn from records available at a point in time. A later record can connect two clusters that were previously separate. Removing an incorrect record or an expired edge can reveal that one cluster actually contains two identities. Deleting the final record removes the entity entirely. Any platform that supports correction must accommodate these changes, even when it works hard to preserve a familiar identifier.

We assign a UUID when a new entity is created and keep that ID as records are added to the same entity. Our entity documentation explains the exceptions. During a merge, one relevant ID is preserved. During a split, one resulting entity normally retains the previous ID while other parts receive new ones. Once an entity and its last record are deleted, re-ingestion does not restore the old ID. These are lifecycle facts, not availability failures.

A downstream table that stores only entity_id without source records, effective time or alias resolution cannot interpret that lifecycle. After a merge, some rows still point to an obsolete ID. After a split, the old ID may now identify only one of several successor entities. Updating every historical row in place seems simple, but it destroys the ability to explain what a report or decision knew at the time.

How should record, entity and business identities be separated?

Source-record identity should be immutable within its declared namespace. Entity identity represents the current grouping produced by a versioned resolution policy. A business object such as an order, case or conversation has its own identifier and may reference the entity view used at a specific time. Keeping these domains separate stops a correction in matching from rewriting the identity of the underlying transaction.

Put an identity-resolution boundary between consumers and raw entity IDs. It can return the current canonical ID for an alias, the lineage of a merge or split, and the entity version effective at a requested time. Consumers that only need a current customer view can follow the canonical mapping. Audit, billing and historical analytics may need the as-of version. The contract should state which semantics each consumer receives.

Aliases are durable references, not duplicate entities. When B merges into A, keep B as a resolvable alias for A with the merge event and effective time. Do not silently recycle B. A split is more complex because one old reference can map to multiple successors. It requires a policy: return the retained successor, require re-resolution from source records, or expose an explicit ambiguous-successor response. Guessing a single successor in every case recreates the original error downstream.

Consumers should process identity change as an event with lineage, not as a silent overwrite of an identifier.

Treat merges and splits as a public event contract

A useful entity-change event has a globally unique event ID, source, type, schema version, occurred and effective times, affected IDs, resulting IDs, resolution-policy version and an idempotency rule. CloudEvents provides a neutral envelope for event identity, source and type. The domain payload then carries merge or split lineage. Do not expose raw personal attributes when the consumer only needs reference maintenance.

Publish events only after the identity change is durable, and preserve their order for each affected lineage. Consumers store the last applied version or event ID and make handlers idempotent. If event 42 is delivered twice, applying it twice must not duplicate a row or repeat a business action. If event 41 arrives after 42, the consumer should detect it as stale rather than silently restoring an older mapping.

Event sourcing is useful here because it records change as an ordered series rather than overwriting state. The AWS pattern guidance highlights immutable events, replay and versioning. A full event-sourced architecture is not mandatory, but the identity lifecycle still needs equivalent evidence: what changed, why, when and how current state can be rebuilt.

A downstream implementation checklist

1. Inventory every consumer. Find tables, caches, features, search indexes, cases and model inputs that persist an entity ID. Classify whether each needs current, historical or event-time semantics.
2. Create a canonical-resolution endpoint. Resolve an entity ID or alias to current lineage through one controlled GraphQL or service boundary. Return explicit deleted and ambiguous-successor states instead of a generic not-found response.
3. Define merge and split schemas. Include event identity, affected and resulting IDs, effective time, policy version and lineage. Version the schema and test compatibility with every supported consumer.
4. Make consumers idempotent. Keep a processing ledger or version cursor. Apply reference changes in a transaction where possible, retry safely and send irrecoverable failures to a visible recovery queue.
5. Keep aliases and tombstones. Prior IDs remain resolvable to their status. A tombstone distinguishes a deleted entity from a temporary lookup failure and prevents accidental ID reuse.
6. Re-resolve after a split. Where the old ID has multiple successors, use the business object’s source-record evidence or an authorised review decision. Do not assign every historical object to whichever successor kept the old ID.
7. Reconcile periodically. Compare consumer references with the canonical identity service, repair missed events and measure lag, stale aliases and unresolved split references. Event delivery and state reconciliation protect against different failure modes.

Three failure modes to test before release

First, test a merge while a consumer is offline. When it returns, it must apply the missed alias change before acting on the old ID. Second, test a split where historical orders belong to different successors. The system must not move all orders to the retained ID merely because it is convenient. Third, test deletion and later re-ingestion. A newly created ID must not be mistaken for a resurrection of the deleted entity without explicit lineage evidence.

Also test cache expiry, duplicate events, reversed delivery order, partial database failure and schema-version mismatch. A perfect happy-path handler is not a lifecycle implementation. Recovery evidence should show which event was last applied, which reference remains stale and whether retry will repeat any business action.

The goal is not to eliminate change. It is to make correction safe. A system that promises an ID can never move may preserve references by preserving a wrong merge. Reliable identity infrastructure allows the grouping to evolve while giving downstream teams a stable contract for understanding that evolution.

What evidence keeps an entity change reversible?

An entity ID identifies a resolution state, while source record IDs identify the observations that produced it. Keep those layers separate. A merge record needs the predecessor entities, retained ID, source records, event time and active decision version. A split also needs the successor entities and the record membership assigned to each one.

Normalised values help matching, but original values remain necessary when a downstream owner must understand why a record moved. Retaining both lets the team replay the relationship, challenge an incorrect edge and assign a business object to the correct successor after a split.

The lifecycle ledger should record creation, merge, split, deletion and alias resolution as versioned events. It gives operational consumers a current canonical reference and gives historical consumers an as-of view without pretending that an earlier grouping never existed.

How do entity changes behave in Tilores?

We create an entity ID when a submitted record does not match an existing entity and keep that ID stable while new records join only that entity. When new evidence merges entities, we retain the most relevant ID, typically the earliest one. When removal causes a split, we retain the original ID for one resulting entity where possible and issue new IDs for the others.

Our entity event stream exposes create, update, merge, split and delete changes for downstream handling. Consumers should process those events idempotently, retain aliases and use the affected record membership to resolve business references. GraphQL remains the boundary for submitting, searching and querying current entity state.

The end-to-end rollout guide covers system ownership and cutover. For this lifecycle, the decisive test is a complete merge, outage, replay and split sequence in which every consumer reaches the correct current state and the historical state remains reproducible.

Frequently asked questions

Are our entity IDs stable?

We keep IDs stable where possible. Our documentation describes cases where merges, splits and deletion change or remove IDs. Downstream systems should therefore implement the lifecycle rather than assume immutability.

Which ID survives a merge?

We normally preserve the most relevant entity ID, typically the oldest. Consumers should rely on the emitted or queried canonical mapping rather than duplicate that selection rule independently.

Which ID survives a split?

One resulting entity generally retains the prior ID, usually the part with the most data, while other parts receive new IDs. Historical objects may still need re-resolution against their source evidence.

Should historical facts be rewritten to the latest entity ID?

Not blindly. Current operational views can resolve aliases, while historical or audited views often need the entity version that was effective when the fact or decision occurred.

What if a consumer misses an entity event?

Use replay plus periodic reconciliation against canonical state. Track consumer cursors and make handlers idempotent so repair does not repeat business effects.

Sources

1. Tilores documentation: What is an Entity?. Entity IDs and merge, split and deletion behaviour.
2. Tilores documentation: Frequently Asked Questions. Current ID stability and rule-change implications for previously ingested records.
3. Tilores documentation: API. GraphQL operations and the entity event stream.
4. Tilores: How to Build Your Own Identity Resolution System. Internal context on merge and split requirements.
5. W3C: PROV Constraints. Revision, invalidation and provenance constraints across versions.
6. CloudEvents specification: JSON format. Required event identity, source, version and type attributes.
7. AWS Prescriptive Guidance: Event sourcing pattern. Immutable ordered events, replay and versioning.
8. Tilores: What an Entity Resolution Rollout Actually Looks Like in 2026. Internal context on labelled truth, parallel running and operational ownership.

The lifecycle patterns here are architectural guidance. Exact retention and correction obligations depend on the data, purpose and applicable policy.