Contact/Organization Model

1. مسئله واقعی: یک Contact Row برای چند حقیقت متفاوت کافی نیست

فرض کنید یک مشاور یک ایمیل شخصی، یک ایمیل شرکتی و سابقه همکاری با دو سازمان دارد. اگر همه‌چیز را در یک ردیف mutable نگه داریم، تغییر شغل می‌تواند تاریخچه را overwrite کند، آدرس مشترک تیمی ممکن است به یک فرد نسبت داده شود و دیگر معلوم نباشد هر مقدار از کدام منبع آمده است. هدف این درس ساخت Contact–Organization Relationship Ledger v1 است؛ مدلی که person، organization، communication point و relationship را از هم جدا می‌کند.

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

PLN-003 identity resolution انجام نمی‌دهد. person_id باید از upstream معتبر آمده باشد؛ تصمیم اینکه دو handle متعلق به یک انسان‌اند در PLN-002 است. این درس فقط می‌پرسد: فرد شناخته‌شده با کدام organization چه رابطه‌ای دارد، آن رابطه در چه بازه‌ای معتبر است و هر communication point متعلق به چه entity-kind است. Opportunity و next action نیز متعلق به PLN-004 هستند.

3. چهار موجودیت را از هم جدا کن

حداقل چهار مفهوم مستقل داریم: Person، Organization، Relationship و Communication Point. Person حقیقت هویتی فرد را نگه می‌دارد؛ Organization یک entity مستقل است؛ Relationship نقش/وابستگی و بازه زمانی را نگه می‌دارد؛ Communication Point مثل email/phone می‌گوید راه ارتباطی به چه owner-kind و owner-id تعلق دارد. ادغام این چهار مفهوم در یک ردیف، تاریخچه و provenance را ضعیف می‌کند.

4. RFC 6350 چه چیزی را ثابت می‌کند و چه چیزی را نه

RFC 6350 vCard را برای نمایش و تبادل اطلاعات افراد و سایر entityها تعریف می‌کند و KIND می‌تواند individual یا org باشد. همین استاندارد propertyهایی مثل EMAIL، TEL، TITLE، ROLE و ORG دارد. اما vCard یک interchange format است؛ الزام نمی‌کند MAKNOW داده را در یک جدول ذخیره کند و truth هویتی یا relational schema ما را تعیین نمی‌کند.

5. Organization یک فیلد متنی روی Person نیست

organization_id باید به یک entity مستقل اشاره کند. نام شرکت، domain و واحد سازمانی attributeهای organization هستند، نه proof هویت شخص. اگر کسی از @example.com ایمیل بزند، آن domain می‌تواند یک signal باشد، اما به‌تنهایی اجازه نمی‌دهد فرد را به organization bind کنیم یا affiliation تاریخی قبلی را پاک کنیم.

6. Affiliation را به Relationship تبدیل کن

رابطه Person↔Organization باید relationship_id مستقل داشته باشد و role, valid_from, valid_to, relationship_status و source_ref را نگه دارد. با تغییر نقش یا کارفرما، person record را overwrite نکن؛ یک relationship را ببند و relationship جدید بساز یا transition را با evidence ثبت کن. این قرارداد طراحی MAKNOW است، نه الزام RFC 6350.

7. هم‌زمانی و تاریخچه خطا نیستند

یک contractor می‌تواند هم‌زمان با دو organization رابطه معتبر داشته باشد. مدل درست نباید صرفاً به‌دلیل overlap یکی را حذف کند. شرط این است که هر affiliation شناسه، source و بازه خودش را داشته باشد. همچنین پایان یک affiliation و شروع دیگری در یک روز می‌تواند معتبر باشد؛ evaluator باید ambiguity واقعی را از transition کاملاً مستند جدا کند.

8. Communication Point مالک دارد

هر email، phone یا address باید owner_kind و owner reference روشن داشته باشد. mailbox مشترک مثل support@company.com ممکن است متعلق به organization باشد، نه شخص. corporate email شخصی می‌تواند به person یا relationship context وصل شود، اما ownership نباید فقط از شکل آدرس حدس زده شود. shared mailbox را به زور داخل person record نگذار.

9. Preferred Channel با Ownership یکی نیست

preferred_channel یک ترجیح ارتباطی است، نه دلیل مالکیت یا identity. ممکن است فرد تماس تلفنی را ترجیح دهد اما شماره متعلق به خط سازمانی باشد؛ یا یک mailbox سازمانی کانال عملیاتی اصلی باشد. ledger باید ownership، preference و validity را جدا نگه دارد تا downstream routing روی فرض اشتباه بنا نشود.

10. Provenance در سطح attribute و relationship

W3C PROV-O اجازه می‌دهد provenance را در domainهای مختلف تخصصی کنیم. در این درس از آن فقط به‌عنوان boundary برای lineage استفاده می‌کنیم: این role، phone، email یا valid_to از کدام source/event آمده و چه زمانی ثبت شده است. PROV schema تماس را تعریف نمی‌کند؛ فقط کمک می‌کند ادعاها قابل‌ردیابی باشند.

11. تغییر Phone را overwrite نکن

اگر شماره جدیدی دریافت شد، مقدار قدیمی را بدون trace حذف نکن. record جدید باید source تازه و validity مناسب داشته باشد و مقدار قبلی historical/inactive شود. اگر هیچ evidence برای شماره جدید وجود ندارد، state را REVIEW_REQUIRED نگه دار. «آخرین مقدار دیده‌شده» همیشه «حقیقت فعلی» نیست.

12. Note Scope را محدود کن

یادداشت contact نباید container بی‌مرز برای اطلاعات شخص، organization و opportunity شود. note_scope باید مشخص کند یادداشت به person، organization یا relationship مربوط است. این جداسازی هم audit را بهتر می‌کند و هم از leakage معنایی به درس‌های مجاور جلوگیری می‌کند.

13. Worked Example: تغییر نقش بدون بازنویسی هویت

شخص P-17 از organization O-A خارج می‌شود و همان روز relationship جدیدی با O-B شروع می‌کند. P-17 ثابت می‌ماند. relationship قدیمی valid_to و source پایان دارد؛ relationship جدید ID مستقل، role و source شروع دارد. corporate email قبلی historical می‌شود، personal email فرد فعال می‌ماند و هیچ organization domain به identity proof تبدیل نمی‌شود. نتیجه EVIDENCE_CLOSED است چون transition کامل و قابل‌ردیابی است.

14. Failure Probeهای قطعی

چهار shortcut باید fail یا به review بروند: (۱) shared mailbox سازمانی با owner_kind=person ثبت شود → REVIEW_REQUIRED؛ (۲) relationship بدون source/provenance ساخته شود → REVIEW_REQUIRED؛ (۳) دو affiliation هم‌زمان صرفاً به‌دلیل overlap merge یا حذف شوند → مدل غلط است و باید مستقل بمانند؛ (۴) phone جدید جای مقدار قبلی را بدون history بگیرد → REVIEW_REQUIRED. در مقابل same-day transition با دو relationship مستقل و evidence کامل می‌تواند معتبر باشد.

15. Transfer: Shared Mailbox + Contractor چندوابستگی

در سناریوی انتقال، partners@north.example یک mailbox متعلق به organization است و contractor هم‌زمان با دو شرکت قرارداد دارد. baseline را کپی نکن. دو relationship مستقل بساز، validity هرکدام را از evidence جدید محاسبه کن، mailbox را به owner-kind سازمانی وصل کن و communication point شخصی contractor را جدا نگه دار. اگر ownership یا source مبهم است، خروجی را REVIEW_REQUIRED نگه دار؛ ambiguity را با حدس پر نکن.