Cross-Channel Identity and Confidence-Based Merge

1. The real problem: similarity is not identity

Three normalized messages show “Sara N.” One email account and one chat account share a verified phone suffix; a second chat account shares only the display name and employer. Merging all three because they look similar contaminates downstream contacts, opportunities, and obligations. This lesson produces Cross-Channel Identity Linkage Decision Matrix v1: a bounded, traceable, reversible decision for each candidate pair.

2. Lesson ownership boundary

PLN-002 does not normalize channel messages; PLN-001 owns that outcome. It also does not model person-to-organization relationships; PLN-003 owns that outcome. This lesson asks whether two source identities plausibly belong to one person, what the exact evidence and contradictions are, and whether the bounded decision is LINKED, KEEP_SEPARATE, or REVIEW_REQUIRED.

3. Start with a candidate pair, not a canonical person

Evaluation begins with a candidate_pair, not an assumption that merging is correct. Preserve raw source identifiers such as email, phone, username, and external customer ID. A canonical_person_id is attached only when visible evidence supports the link; otherwise the identities remain separate or under review.

4. What AWS Entity Resolution demonstrates

AWS Entity Resolution is a vendor reference whose matching workflows process input data and assign Match IDs to matched records. It supports configurable rule-based matching and machine-learning-based matching, and ML matching can return confidence-level percentages. This demonstrates that matching can expose rule/model metadata and confidence outputs; it does not make an AWS Match ID the MAKNOW canonical identity or define a universal merge threshold.

5. Separate strong, supporting, and shared features

The synthetic fixture uses three feature roles: strong evidence such as a stable external customer ID or verified phone; supporting evidence such as a verified corporate domain; and weak/shared evidence such as display name or employer. A shared name and company can justify candidate generation, but not identity proof. Lab weights and thresholds are local exercise policy only.

6. Every decisive feature needs provenance

Each feature must expose its source_id, verification state, and provenance. If two records share a phone suffix, the matrix must show which normalized message or directory produced that fact and whether it was verified. A score without traceable evidence is not auditable; missing provenance on a decisive feature constrains the result to REVIEW_REQUIRED.

7. Confidence is an evidence summary, not authorization

A confidence_score summarizes visible evidence; it does not authorize a merge. Several positive signals may produce a high score while a strong contradiction—such as distinct verified customer IDs or incompatible verified phones—changes the decision. The correct order is evidence → contradiction check → confidence band → bounded decision, never score → merge.

8. Keep contradiction override independent

contradictions must be an explicit column. If records share a name and domain but have different verified customer IDs, that contradiction must not disappear inside an average. When strong positive and strong contradictory evidence coexist, this lesson defaults to REVIEW_REQUIRED. When reliable evidence clearly supports distinct identities, KEEP_SEPARATE is allowed.

9. Reversibility is a linkage requirement

A link must record reversible_link=true, a merge/link reason, and unmerge_evidence. The lesson does not authorize destructive merging; it records a reversible alias/link. If the only available action is irreversible consolidation without trace, even a high score is insufficient and the result remains REVIEW_REQUIRED.

10. Respect shared-attribute risk

Corporate domains, employers, and display names are shared attributes. A verified domain strengthens the organizational context, not person identity. Therefore name + company or name + domain may create a candidate pair, but LINKED requires stronger evidence, provenance, and the absence of decisive contradictions.

11. Use the three decision states precisely

LINKED means the synthetic evidence is sufficient, consistent, provenance-complete, and the link is reversible. KEEP_SEPARATE means visible evidence supports distinct identities or there is no sufficient basis to link and reliable contradiction supports separation. REVIEW_REQUIRED covers mixed evidence, missing provenance, strong contradictions alongside positive signals, or non-reversible actions.

12. Worked example: two channels with a verified phone

Pair E-17 ↔ C-44 shares a verified phone suffix and the same stable external customer ID; the display name also aligns. Both strong features have traceable provenance and there is no contradiction. Under the lab-only policy, the confidence band is HIGH. Because the link is reversible and unmerge evidence is recorded, the bounded decision is LINKED—for this fixture only.

13. Worked negative: same name and employer

Pair C-51 ↔ C-77 shares a display name and employer but no strong shared phone or email evidence, and the external customer IDs differ. Shared attributes are enough to generate a candidate, not enough to prove identity. If both distinct external IDs are verified, keep the pair KEEP_SEPARATE; if evidence quality is incomplete, use REVIEW_REQUIRED instead.

14. Deterministic failure probes

Four shortcuts must fail: (1) high score plus a verified contradiction → REVIEW_REQUIRED; (2) decisive feature without provenance → REVIEW_REQUIRED; (3) reversible_link=false with a proposed merge → REVIEW_REQUIRED; (4) display name + employer only → never LINKED. By contrast, two distinct verified stable external IDs can support KEEP_SEPARATE.

15. Transfer: no phone, stable customer ID

The transfer removes phone evidence. Two accounts share a verified corporate domain and the same stable external customer ID. Do not copy the baseline label. Rebuild features, recompute the lab-only score/band, check contradictions independently, and preserve customer-ID provenance. If the shared ID is verified and no strong contradiction exists, the pair can be LINKED; ambiguous verification or provenance must remain REVIEW_REQUIRED.