> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/sdgm/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/sdgm/_mcp/server.

# Entity Resolution

Decide which accounts on two different platforms belong to the same real-world person, so their records can be merged into one profile. For each platform-A user, this example ranks the platform-B users most likely to be the same person, using a pre-generated labels table of high-confidence matches as ground truth. The target is a fixed set of matching accounts rather than a future event, so this is a static link prediction task.

## Data and relationships

The example assumes a prepared Kumo Engine `graph`, a matching `snapshot`, and these tables:

| Table              | Required columns                                                    | Purpose                                                                                                                                    |
| ------------------ | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `platform_a_users` | `platform_a_user_id` as the primary key, plus `first_seen`          | The platform A users to resolve. `first_seen` is the account creation date, kept as an ordinary attribute.                                 |
| `platform_b_users` | `platform_b_user_id` as the primary key, plus `first_seen`          | The platform B users to match against, carrying the same kind of attributes as platform A.                                                 |
| `labels`           | `link_id`, `platform_a_user_id`, `platform_b_user_id`, `confidence` | Pre-generated ground-truth links between an A user and a B user. `confidence` records how strong each link is, such as `High` or `Medium`. |

Connect `labels.platform_a_user_id` to `platform_a_users.platform_a_user_id` and `labels.platform_b_user_id` to `platform_b_users.platform_b_user_id`, so each labeled row joins the two accounts it matches. The labels table is prepared before training from a trusted signal, such as two accounts that share an email address, and it defines the ground truth the model learns from. Its `confidence` column lets the query train on only the strongest links, which keeps low-quality pairs out of the labels. Because matching is a static decision rather than a time-ordered event, this graph uses no time column: the labels table has none, and each user table's `first_seen` stays an ordinary attribute rather than a time anchor. You can fold in more matching signals, such as shared sessions or devices, as extra tables connected to both user tables the same way, but they are optional.

## Rank the most likely matching accounts

This query ranks, for each platform-A user, the platform-B users most likely to be the same person. `LIST_DISTINCT` collects each candidate B user once, `WHERE labels.confidence='High'` restricts the targets to high-confidence links so the model trains only on trustworthy matches, `RANK TOP 10` returns up to ten ranked B candidates, and `FOR EACH platform_a_users.platform_a_user_id` produces one ranked list per A user.

```python
from kumo.engine import PredictiveQuery

query_text = (
    "PREDICT LIST_DISTINCT(labels.platform_b_user_id WHERE labels.confidence='High') "
    "RANK TOP 10 FOR EACH platform_a_users.platform_a_user_id"
)
query = PredictiveQuery(graph, query_text)
query.validate()
print(query.get_task_type())  # static_link_prediction
```

## Reading the predictions

Each platform-A user gets a ranked list of up to ten candidate platform-B users, ordered by how likely Kumo Engine judges each candidate to be the same person. The list narrows the accounts worth reviewing; it does not confirm a match or guarantee that a duplicate exists across the two platforms, so treat the top candidates as the pairs most worth verifying. Verify candidate matches before merging records. As verified pairs accumulate, add them to the labels table so the next model trains on a larger set of ground-truth matches.