Cross-channel Identity و Confidence-based Merge

1. مسئله واقعی: شباهت، هویت نیست

سه پیام نرمال‌شده نام «Sara N.» را نشان می‌دهند. یک ایمیل و یک حساب چت suffix تلفن تأییدشده‌ی یکسان دارند؛ حساب چت دوم فقط display name و شرکت مشابه دارد. اگر صرفاً به خاطر شباهت ظاهری همه را merge کنیم، آلودگی identity به contact، opportunity و obligationهای بعدی منتقل می‌شود. خروجی این درس Cross-Channel Identity Linkage Decision Matrix v1 است: تصمیمی محدود، قابل‌ردیابی و قابل‌برگشت درباره‌ی candidate pairها.

2. مرز مالکیت درس

PLN-002 پیام‌های کانال‌ها را normalize نمی‌کند؛ آن کار متعلق به PLN-001 است. همچنین person↔organization relationship را نمی‌سازد؛ آن outcome متعلق به PLN-003 است. این درس فقط می‌پرسد آیا دو source identity احتمالاً یک person هستند، evidence دقیق چیست، contradiction کجاست و تصمیم باید LINKED، KEEP_SEPARATE یا REVIEW_REQUIRED باشد.

3. Candidate Pair قبل از Canonical Person

هر ارزیابی با یک candidate_pair شروع می‌شود، نه با فرض اینکه merge درست است. source identifierهای خام مثل email، phone، username یا external customer ID باید حفظ شوند. canonical_person_id فقط وقتی ساخته یا به link متصل می‌شود که evidence کافی و قابل‌ممیزی وجود داشته باشد؛ در غیر این صورت pair مستقل می‌ماند.

4. AWS Entity Resolution چه چیزی را نشان می‌دهد

AWS Entity Resolution یک مرجع vendor است که matching workflowها را روی inputهای مختلف اجرا می‌کند و برای recordهای matched، Match ID تولید می‌کند. rule-based workflowها قابل‌پیکربندی‌اند و ML-based workflow می‌تواند confidence level percentage بدهد. این رفتار نشان می‌دهد matching می‌تواند rule/model و output metadata داشته باشد؛ اما Match ID یا confidence AWS، canonical identity یا threshold جهانی MAKNOW را تعریف نمی‌کند.

5. Featureها را به سه سطح تقسیم کن

در fixture این درس featureها سه نقش دارند: قوی مثل stable external customer ID یا verified phone؛ حمایتی مثل verified corporate domain؛ و ضعیف/shared مثل display name یا employer. نام و شرکت مشترک candidate generation را توجیه می‌کند اما به‌تنهایی proof merge نیست. وزن‌ها و thresholdهای Lab صرفاً policy مصنوعی همین تمرین‌اند.

6. Provenance هر Feature باید دیده شود

هر feature باید source_id، نوع verification و provenance داشته باشد. اگر نوشته‌ایم phone suffix یکسان است، باید معلوم باشد از کدام normalized message یا directory آمده و آیا verified بوده است. score بدون provenance قابل دفاع نیست؛ وقتی feature decisive منبع قابل‌ردیابی ندارد، تصمیم باید به REVIEW_REQUIRED محدود شود.

7. Confidence Score فقط Summary است

confidence_score خلاصه‌ی evidence است، نه authorization. ممکن است مجموع signalهای مثبت score بالایی بدهد، ولی یک contradiction قوی مثل دو stable external customer ID متفاوت یا verified phoneهای ناسازگار، نتیجه را عوض کند. ترتیب درست این است: evidence → contradiction check → confidence band → bounded decision؛ نه score → merge.

8. Contradiction Override را مستقل نگه دار

contradictions یک ستون مستقل است. اگر دو record نام و domain یکسان دارند اما verified customer ID متفاوت است، contradiction نباید داخل میانگین گم شود. وقتی evidence مثبت و contradiction قوی هم‌زمان دیده می‌شود، خروجی پیش‌فرض این درس REVIEW_REQUIRED است. اگر evidence قوی و سازگار نشان دهد دو identity جدا هستند، KEEP_SEPARATE مجاز است.

9. Reversibility شرط Link است

هر link باید reversible_link=true، merge_reason و unmerge_evidence داشته باشد. هدف، destructive merge نیست؛ هدف ثبت alias/link قابل‌برگشت است. اگر سیستم فقط یک merge دائمی بدون trace ارائه می‌دهد، حتی score بالا برای این درس کافی نیست و تصمیم باید REVIEW_REQUIRED بماند.

10. Shared Attribute Risk را جدی بگیر

corporate domain، employer و display name می‌توانند بین چند نفر مشترک باشند. حتی verified domain فقط ownership سازمانی دامنه را تقویت می‌کند، نه person identity را. بنابراین name + company یا name + domain candidate generation می‌سازد؛ برای LINKED به evidence قوی‌تر، provenance و نبود contradiction نیاز داریم.

11. سه Decision State را دقیق استفاده کن

LINKED یعنی در fixture مصنوعی، evidence کافی، سازگار، دارای provenance و link قابل‌برگشت است. KEEP_SEPARATE یعنی evidence visible به‌طور روشن دو identity مستقل را پشتیبانی می‌کند یا support کافی برای link وجود ندارد و contradiction جدایی را تقویت می‌کند. REVIEW_REQUIRED برای evidence mixed، provenance ناقص، contradiction قوی همراه signal مثبت، یا link غیرقابل‌برگشت است.

12. Worked Example: دو Channel با Phone تأییدشده

Pair E-17 ↔ C-44 همان verified phone suffix و همان stable external customer ID را دارد؛ display name هم سازگار است. هر دو feature قوی provenance روشن دارند و contradiction ثبت نشده است. در policy مصنوعی Lab، confidence band به HIGH می‌رسد؛ چون link reversible است و unmerge evidence تعریف شده، تصمیم LINKED است. این نتیجه فقط درباره‌ی fixture است، نه threshold جهانی.

13. Worked Negative: اسم و شرکت مشترک

Pair C-51 ↔ C-77 display name و employer یکسان دارد اما phone/email قوی مشترک ندارد و external customer ID هم متفاوت است. shared attributes برای candidate generation کافی‌اند اما برای identity proof نه. اگر external IDهای متفاوت هر دو verified باشند، pair باید KEEP_SEPARATE بماند؛ اگر بخشی از evidence ناقص باشد، REVIEW_REQUIRED مناسب‌تر است.

14. Failure Probeهای قطعی

چهار shortcut باید fail شوند: (۱) score بالا همراه verified contradiction → REVIEW_REQUIRED؛ (۲) feature decisive بدون provenance → REVIEW_REQUIRED؛ (۳) reversible_link=false با پیشنهاد merge → REVIEW_REQUIRED؛ (۴) فقط display name + employer مشترک → هرگز LINKED نشود. در مقابل دو stable external ID متفاوت و معتبر می‌توانند KEEP_SEPARATE را پشتیبانی کنند.

15. Transfer: بدون Phone، با Customer ID پایدار

در Transfer تلفن حذف می‌شود. دو account یک verified corporate domain و همان stable external customer ID دارند. baseline را کپی نکن: featureها را از نو بساز، score/band را طبق policy مصنوعی محاسبه کن، contradiction را مستقل بررسی کن و provenance customer ID را ثبت کن. اگر customer ID واقعاً verified و مشترک است و contradiction قوی نداریم، link می‌تواند LINKED باشد؛ اگر verification یا provenance مبهم است، REVIEW_REQUIRED را حفظ کن.