Entity Resolution and the Instability Problem
The Problem Solution 1: Make the API record‑centric, not entity‑centric Solution 2: Introduce your own stable external Entity ID and map it to Senzing 2.1. Public vs internal IDs 2.2. Handling merges 2.3. Handling splits 2.4. Pros / Cons Solution 3: Provide an entity change feed (events) for downstream sync 3.1. Why? 3.2. Event model Solution 4: Treat entity IDs as ephemeral handles with TTL semantics Solution 5: Event‑sourcing / versioned entities (for heavy compliance/audit use‑cases) FrankenRes Internals API surface Detecting Splits and Merges with Senzing 1. What Senzing actually provides 2. Minimum state you need to track 3. Robust per-event processing pattern Concurrency safeguard Split vs Merge Detection Detecting splits Detecting merges A simplier way without splits and merges Senzing Lifecycle Detector C# Implementation Single-file example Usage TL;DR The Problem The classic entity resolution gotcha: the thing that looks like a primary key (e.g. Senzing’s entity ID) is actually a volatile cluster ID that can legitimately change as the engine learns. Senzing explicitly says their resolved entity ID is not a globally unique persistent identifier and that it’s just an identifier for a grouping that may be transient. (senzing.zendesk.com) ...