Opportunity Dossier و Next Action

1. مسئله واقعی: «فرصت» از چند پیام پراکنده ساخته نمی‌شود

پنج پیام درباره یک پایلوت احتمالی داریم: یک پیام مشتاق است، دیگری می‌گوید بودجه هنوز تأیید نشده و آخرین پیام یک technical brief برای سه‌شنبه می‌خواهد. اگر فقط یک label مثل «Qualified» بسازیم، evidence، فرض‌ها و اقدام بعدی گم می‌شوند. هدف این درس ساخت Opportunity Decision Dossier & Next-Action Ledger v1 است؛ پرونده‌ای که تصمیم را از sourceهای قابل‌ردیابی می‌سازد و optimism را جای certainty نمی‌نشاند.

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

PLN-004 مالک dossier فرصت است، نه identity resolution و نه deadline-risk. contact_refs و organization_ref را از upstream مصرف می‌کنیم، اما merge identity متعلق به PLN-002/003 است. همچنین اگر next action بعداً به یک obligation واقعی تبدیل شود، lifecycle آن متعلق به PLN-005 است. این مرز مانع می‌شود یک «فرصت» به ظرف همه workflowها تبدیل شود.

3. Source Binding: هر ادعا باید به مدرک برگردد

هر dossier باید source_refs دقیق داشته باشد. پیام «علاقه‌مندیم» می‌تواند evidence برای interest باشد، اما به‌تنهایی proof برای budget، authority یا win نیست. در decision history هر تغییر stage باید به source یا observation قابل‌بررسی وصل شود. summary تولیدشده توسط AI منبع اصلی محسوب نمی‌شود؛ فقط نمای کمکی است.

4. Provenance چه چیزی اضافه می‌کند

W3C PROV چارچوبی برای ربط‌دادن entity، activity و agent فراهم می‌کند. در این درس از آن به‌عنوان boundary مفهومی provenance استفاده می‌کنیم: کدام message/entity روی کدام تصمیم اثر گذاشت و چه agent انسانی مسئول تصمیم بود. PROV sales stage یا opportunity policy تعریف نمی‌کند؛ stage names قرارداد طراحی MAKNOW هستند.

5. Objective و Value Hypothesis را از Fact جدا کن

objective چیزی است که opportunity می‌خواهد به آن برسد؛ value_hypothesis توضیح آزمون‌پذیر ما درباره ارزش احتمالی است. فرضیه ارزش نباید به factual claim تبدیل شود. «کاهش زمان onboarding شاید ارزش ایجاد کند» با «مشتری 30٪ صرفه‌جویی را تأیید کرده» فرق دارد. تا وقتی evidence مستقیم نداریم، hypothesis باید همان hypothesis بماند.

6. Stage فقط label نیست؛ Stage Reason اجباری است

Stage بدون stage_reason auditپذیر نیست. Stage باید به evidence موجود و missing evidence حساس باشد. اگر تنها مدرک پشتیبان stage حذف شود، evaluator باید stage را downgrade یا REVIEW_REQUIRED کند. این درس عمداً stage را از confidence جدا می‌کند: ممکن است stage مشخص باشد اما confidence پایین باشد، یا برعکس.

7. Confidence عدد جادویی نیست

Confidence یک خلاصه طراحی‌شده از completeness و consistency evidence است، نه احتمال آماری واقعی. عدد یا برچسب confidence باید explainable باشد: چه sourceهایی آن را بالا بردند، چه contradiction یا unknownهایی آن را محدود کردند. High confidence بدون source coverage کافی قابل‌قبول نیست.

8. Open Questions بخشی از evidence هستند

سؤال‌های باز ضعف dossier نیستند؛ مرز uncertainty را نشان می‌دهند. «بودجه چه زمانی تأیید می‌شود؟»، «decision maker چه کسی است؟» و «آیا technical brief برای ارزیابی procurement لازم است؟» باید در open_questions بمانند تا به‌اشتباه به fact تبدیل نشوند. هر سؤال باید یا next action، blocker یا recheck مرتبط داشته باشد.

9. فقط یک Next Action اصلی

یک opportunity فعال باید دقیقاً یک اقدام accountable داشته باشد؛ مثلاً «ارسال technical brief». اگر دو اقدام هم‌زمان هر دو primary باشند، ownership و sequencing مبهم می‌شود و خروجی REVIEW_REQUIRED است. اقدام‌های فرعی می‌توانند backlog باشند، اما ledger باید یک next_action اصلی و یک owner روشن داشته باشد.

10. Due Date اجباری نیست؛ Due or Recheck اجباری است

RFC 5545 نشان می‌دهد task representation می‌تواند due/status داشته باشد، اما MAKNOW فرصت را مجبور به deadline ساختگی نمی‌کند. اگر external procurement decision هیچ تاریخ قطعی ندارد، due_or_recheck باید یک شرط finite مثل «وقتی procurement portal نتیجه را منتشر کرد یا تا 10 روز دیگر review کن» باشد. نبود deadline نباید urgency جعلی بسازد.

11. BLOCKED، DEFERRED و NO_ACTION_REQUIRED را جدا نگه دار

BLOCKED یعنی action معنادار داریم اما dependency مانع است. DEFERRED یعنی فعلاً action اجرایی نداریم و فقط recheck trigger داریم. NO_ACTION_REQUIRED یعنی با evidence فعلی اقدام لازم نیست، نه اینکه فرصت موفق شده باشد. این stateها جلوی فشار بی‌دلیل برای «همیشه یک task بساز» را می‌گیرند.

12. Decision History را append-only نگه دار

هر تغییر stage/status باید timestamp، actor، source refs، previous state، new state و rationale داشته باشد. history را overwrite نکن. اگر opportunity به LOST بسته شد، closed_reason و source آن ثبت می‌شود. اگر evidence جدید بعداً reopen_trigger را برآورده کرد، یک transition جدید ثبت کن؛ گذشته را بازنویسی نکن.

13. Worked Example: Pilot با Budget نامشخص

از پنج پیام، evidence علاقه و درخواست technical brief داریم اما budget هنوز unknown است. stage را «EVALUATING» نگه می‌داریم، stage_reason را به messageهای درخواست/interest وصل می‌کنیم، confidence را متوسط می‌گذاریم، سؤال budget را باز نگه می‌داریم و next action را «ارسال brief» با owner مشخص ثبت می‌کنیم. نتیجه ACTIVE_ACTION است، نه WON.

14. Failure Probeهای قطعی

چهار shortcut باید fail شوند: (۱) تنها evidence پشتیبان stage حذف شود → REVIEW_REQUIRED؛ (۲) دو action هر دو primary باشند → REVIEW_REQUIRED؛ (۳) due date unknown ولی recheck event معتبر باشد → DEFERRED بدون urgency جعلی؛ (۴) opportunity به LOST بسته شده و سپس source جدید reopen trigger را ارضا کند → history حفظ و state دوباره از evidence محاسبه شود، نه حذف closure قبلی.

15. Transfer: Procurement بدون Deadline

در context جدید، partner منتظر تصمیم procurement بیرونی است و هیچ calendar deadline معتبری نداریم. یک تاریخ حدسی نساز. blocked_by=external_procurement را ثبت کن، status را DEFERRED بگذار، next action اجرایی را خالی نگه دار و due_or_recheck را به یک event قابل‌مشاهده یا review date محدود وصل کن. decision baseline را کپی نکن؛ dossier را از evidence جدید بازسازی کن.