Entityresolution

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 What Senzing actually provides (the barebones) Minimum state you need to track Robust per-event processing pattern Concurrency safeguard Split vs Merge Detection Detecting splits Detecting merges A simplier way 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) ...

Context Record vs Entity vs Relationship Data Quality Issues ER Addresses Senzing Repository Key Senzing Attributes Resolution Concepts Features Feature Scores Match Levels Senzing V4 SDK Setup on Metal Native Senzing SDK Setup .NET SDK Setup Setup Local NuGet Source Senzing V4 C# Snippets Senzing V4 CLI Tools sz_configtool listFeatures listAttributes listRules listFragments principles sz_explorer get how (tree) Senzing Weirdness Typed models vs loose JSON strings TODO Info Messages aka SZ_WITH_INFO Senzing Best practices Resources Context The process of identifying and linking records that refer to the same real-world entity across different data sources, even when the records contain variations, errors, or incomplete information. ...