Identity Resolution Review: Merge Proposals With Reason Codes From an AI Agent on Rails

Who this is for: identity stewards, data architects and DPOs. This page belongs to the AI agent rails method and the data and analytics playbook. For the matching mechanics, read identity resolution explained.

Before: the manual workflow

The manual identity review is a steward working through uncertain pairs from the matching engine, usually the band between auto-merge and no link. Each pair means comparing fields, checking history and often opening source systems. Queues grow, so thresholds drift to shrink them. Decisions sit in tickets, so the same pair can return next month. Consent rarely appears on the review screen.

Why can a false merge leak one person's data?

A false merge leaks data because every downstream system treats the merged profile as one person, so anything keyed to it can reach the wrong human. The table shows where that happens.

A false split costs less, though not nothing. An unsubscribed person can get mail through a second profile unless suppression sits on the identifier, and an access request can miss records.

What happens to consent when profiles merge?

Consent should follow the most restrictive state per purpose and channel, with suppression kept on the identifier, as identity resolution explained and the suppression architecture set out. On this rail a rule service computes the before and after state and attaches it to the proposal. The model never calculates consent, and the steward sees the effect before deciding.

Why does a person apply every change?

A person applies every change because merges are hard to reverse, errors fall on individuals, and the session already holds sensitive data.

• Reversal is uneven. Reltio's merge page says the merged profile no longer exists 8. Segment's settings page does not describe undoing merges 9. Adobe says to contact its team to fix collapsed graphs 10. Ask each vendor in writing.
• Averages hide harm. High overall precision still leaves specific people with the wrong data.
• Accountability. GDPR Article 5 requires accuracy and the ability to show compliance, and Article 16 gives a right to correction 23.
• The Rule of Two. The session holds sensitive features, and field values began as untrusted input from forms and feeds 5. It must not also hold the power to change state.

So the level stays at L2 and does not move up, as the rail levels explain. This describes the agent, not the engine. Exact matches on agreed keys can still auto-merge in the identity engine, under thresholds that stewards own through change control. This rail covers the review band only.

After: the job on rails, step by step

The identity review on rails keeps the engine's evidence as the source, adds a proposal, and leaves the write with the steward.

1. Trigger. The identity engine places a pair in the review queue.
2. Rules filter. Blocked values, hard conflicts, legal holds and open access requests are flagged first.
3. Agent proposes. The Identity Reviewer reads pseudonymised features, scores and merge history, then proposes merge, split or keep apart, with reason codes and a confidence.
4. Services check. A validator rejects any reason code with no matching feature. A rule service attaches the consent preview.
5. Steward decides. The steward sees the evidence first, then the proposal, and applies or rejects it in the engine's own console. A second steward reviews any change that alters consent state.
6. Engine writes. The change becomes an event with lineage. Downstream systems re-key, and suppression stays on identifiers.
7. Learning. Decisions and reversals feed the labelled set through the Trainer.

A split takes more care than a merge. Recompute both profiles from identifier-level history, re-key downstream, then list what was sent while the two were merged. The DPO assesses that list. Article 33 sets a 72-hour clock for a notifiable breach, and 33(5) requires a record of every breach 11.

What rules do and what the model does

Rules and the engine produce the evidence and enforce limits, while the model reads across fields for patterns a threshold misses, such as whether two records describe one person or a household.

What does a good reason code look like?

A good reason code names one piece of evidence a reviewer can check, and it comes from a versioned catalogue, not the model's narration. The explainable AI article explains why an explanation must reflect what the system actually did. The catalogue below is illustrative, so build your own with your stewards.

Engines can supply the raw material. Splink's waterfall chart shows how each comparison adds to or subtracts from one pair's match weight 6. Senzing describes "why", "why not" and "how" functions that return match detail and an entity's history 12. Ground codes in evidence like that, so the agent translates and does not invent.

The rail card

The rail card below fixes what the Identity Reviewer may do, and systems enforce each limit, so a prompt cannot widen it.

Run it on a private model inside your environment, as the on-premise LLM article describes, with no external model for this data. PrivyCDP's AI layer offers limits on data access and review of results, and its immutable audit ledger records each AI-assisted action with the human or system actor that authorised it.

What the ledger shows for one run

The ledger entry for one run shows what was proposed, on what evidence and who decided, with records held by reference. The JSON is illustrative: its fields and values are invented, and it is not a product API.

{
  "rail": "identity-reviewer",
  "correlation_id": "c-41d2",
  "candidates_ref": "pair-88213",
  "proposal": "keep_apart",
  "reason_codes": ["N-HOUSE", "N-SHARED"],
  "consent_preview_ref": "cp-7731",
  "decision": {"outcome": "keep_apart", "by_role": "identity steward", "steward_ref": "u-112"},
  "model_version": "private-model-v3"
}

Three ways it fails, and the control for each

The Identity Reviewer fails in ways specific to merging people, and each control below sits outside the model.

Metrics that are honest

Honest metrics for identity review measure correctness on known pairs and reversals over time, not queue speed alone. Baseline each before the agent starts.

• Precision on labelled pairs, including known false merges, by reason code.
• Merge reversal rate. Reversals lag, so sample recent merges too.
• Seeded false merges caught in the live queue.
• Cluster-size outliers, which often signal collapse.
• Override rate. A rate near zero may mean rubber-stamping.
• Audit coverage. Anything below 100% is a defect.

Report by rail, role and reason code, not by named steward. Annex III point 4(b) of the EU AI Act lists monitoring workers' performance as a high-risk use 4, so take advice before building a per-person view.

How vendor tools compare

Vendor tools differ most on whether they offer a review queue and how they reverse a merge. The table records each page, checked on 1 November 2026. "Not stated" means the page opened did not say, not that the feature is absent.

A master data tool with a steward console is often the better answer, particularly if you already run one. A script is enough when matching is deterministic, because the job is then key hygiene and blocked values, with no queue to review. Choose this agent only if your queue is large, your patterns are hard to write as rules, and you can run a private model. If the queue is small, a steward with good evidence on screen needs no agent.

Checklist

Use this checklist before the agent reads a live queue.

• ☐ The engine exposes match evidence, thresholds and versions.
• ☐ Features are pseudonymised, with no sensitive attributes or raw contact details.
• ☐ A versioned reason-code catalogue exists, and a validator enforces it.
• ☐ A rule service computes the consent preview using most-restrictive logic.
• ☐ Suppression sits on identifiers and survives merge, split and erasure.
• ☐ The steward sees evidence before the proposal.
• ☐ A cluster-size limit is set, with an alert.
• ☐ A labelled set includes known false merges, and is rerun on any model, prompt or tool change.
• ☐ A split procedure covers re-keying and a DPO review of what was sent.

Back to the AI agent rails hub. To write this rail for your own team, download the rail card template.