برنامه‌ریزی، تحلیل و عملیات پلتفرم · فصل ۱ — Message، Identity، Contact، Opportunity و Obligation · 196
Obligation Lifecycle و Deadline Risk
داده و event دارد اما آن‌ها را به مدل تصمیم، attention، experiment یا platform policy قابل توضیح تبدیل نمی‌کند. موضوع جاری: «Obligation Lifecycle و Deadline Risk». می‌تواند برای «Obligation Lifecycle و Deadline Risk» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.
خلاصهٔ درس
داده و event دارد اما آن‌ها را به مدل تصمیم، attention، experiment یا platform policy قابل توضیح تبدیل نمی‌کند. موضوع جاری: «Obligation Lifecycle و Deadline Risk».
می‌تواند برای «Obligation Lifecycle و Deadline Risk» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.
خروجی این درس
می‌تواند برای «Obligation Lifecycle و Deadline Risk» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.
1. مسئله واقعی: یک تاریخ به‌تنهایی «تعهد» نیست
جمله‌ای مثل «برآورد امضاشده را تا جمعه بفرست» فقط وقتی قابل پیگیری است که بدانیم این تعهد از کدام پیام آمده، owner و counterparty چه کسانی‌اند، تاریخ دقیق چه semanticsی دارد و چه evidenceای آن را بسته می‌کند. این درس Obligation Lifecycle & Deadline-Risk Register v1 را می‌سازد تا تاریخ، lifecycle و evidence از هم جدا بمانند.
2. مرز درس و Artifact مالک
هر obligation باید حداقل obligation_id، source_ref، متن تعهد، owner، counterparty، زمان ایجاد، due date/time، timezone یا all-day flag، status، blocker، risk window/level، completion evidence، supersession link و recheck را نگه دارد. Opportunity Dossier متعلق به PLN-004 و Notification Routing متعلق به PLN-006 است؛ این درس آن outcomeها را جذب نمی‌کند.
3. Source Binding قبل از هر Risk Calculation
تعهدی که source_ref ندارد auditپذیر نیست. باید بتوانیم دقیقاً به message/meeting note یا record مصنوعی برگردیم که commitment را ایجاد کرده است. یک summary یا reminder downstream جای source اولیه را نمی‌گیرد؛ source binding باید قبل از تصمیم deadline-risk بسته شود.
4. Timed Due و All-day Due یک چیز نیستند
due_at یک instant/زمان مشخص است و برای تفسیر درست به timezone یا offset معتبر نیاز دارد. due_date برای obligation تمام‌روزه می‌تواند فقط تاریخ باشد. تبدیل خام یک تاریخ all-day به «ساعت 00:00 محلی» می‌تواند deadline جعلی بسازد؛ در Register باید نوع semantics صریح باشد.
5. RFC 5545 چه چیزی را ثابت می‌کند و چه چیزی را نه
RFC 5545، VTODO را برای action-item/assignment تعریف می‌کند و در آن DUE یا DURATION را با constraints مشخص می‌پذیرد؛ همچنین STATUS و COMPLETED برای نمایش وضعیت و زمان تکمیل وجود دارند. این‌ها boundary استاندارد تقویم‌اند، نه اثبات اینکه یک تعهد تجاری واقعاً انجام شده است.
6. Lifecycle Stateها باید معنای مستقل داشته باشند
در این درس stateهای اصلی ACTIVE، BLOCKED، COMPLETED، CANCELED و SUPERSEDED هستند. BLOCKED یعنی تعهد هنوز زنده است اما dependency مانع اقدام شده. SUPERSEDED یعنی record قبلی با record جدید جایگزین شده و نباید هم‌زمان active بماند. COMPLETED بدون evidence معتبر مجاز نیست.
7. BLOCKED به معنی حذف Deadline Risk نیست
اگر estimate منتظر legal review باشد، obligation بسته نشده است. blocker باید در blocked_by ثبت شود، اما due semantics همچنان حفظ می‌شود و risk می‌تواند بالا برود. Register باید هم dependency را نشان دهد و هم اینکه deadline نزدیک یا گذشته است.
8. Risk Window از Due Semantics مشتق می‌شود، نه برعکس
risk_window و risk_level پارامترهای طراحی MAKNOW هستند. ابتدا due semantics را دقیق می‌کنیم؛ بعد بر اساس فاصله تا due، status و blocker یک risk محدود می‌سازیم. اگر timezone یا interpretation ناقص باشد، risk نباید با حدس محاسبه شود؛ خروجی UNKNOWN/REVIEW_REQUIRED است.
9. Overdue فقط برای Due قابل تفسیر معتبر است
اگر instant معتبر گذشته و obligation هنوز ACTIVE/BLOCKED باشد، overdue_state می‌تواند overdue شود. اما اگر timezone برای یک timed due مفقود است، اعلام «overdue» قطعی قابل دفاع نیست. اول ambiguity را ثبت کن، بعد recheck یا review را زمان‌بندی کن.
10. Completion Evidence شرط بسته‌شدن است
Reminder ارسال‌شده، calendar event syncشده یا transport success هیچ‌کدام fulfillment evidence نیستند. برای COMPLETED باید مدرکی مثل signed-file receipt، accepted submission، approved record یا evidence مصنوعی معادل وجود داشته باشد و completed_at با آن سازگار باشد. در غیر این صورت وضعیت REVIEW_REQUIRED می‌ماند.
11. Cancellation هم Closure Reason می‌خواهد
CANCELED یک failure تصادفی یا حذف سطر نیست. باید canceled_reason و authority/record مجاز برای closure وجود داشته باشد. اگر فقط «دیگر انجامش نده» در یک summary غیرقابل‌ردیابی دیده شود، cancellation قطعی نیست و باید ambiguity حفظ شود.
12. Supersession باید Chain قابل حسابرسی بسازد
وقتی deadline اصلاح می‌شود، record قبلی را بازنویسی نکن. record قدیمی را SUPERSEDED کن، superseded_by را به record جدید وصل کن، sequence/version را جلو ببر و فقط successor را ACTIVE نگه دار. این کار history را حفظ می‌کند و مانع دو deadline فعال برای یک commitment می‌شود.
13. Worked Example: Friday + Legal Review
پیام مشتری می‌گوید «signed estimate را تا Friday بفرست». timestamp پیام local است، owner در timezone دیگری کار می‌کند و پیام بعدی می‌گوید estimate منتظر legal review است. نتیجه درست BLOCKED_RISK است: source روشن، owner/counterparty روشن، due semantics قابل تفسیر، blocker فعال، completion evidence خالی و recheck قبل از deadline. ارسال reminder این obligation را completed نمی‌کند.
14. Failure Probeهای قطعی
سه shortcut باید fail شوند: (۱) timed due بدون timezone → REVIEW_REQUIRED؛ (۲) status=COMPLETED بدون fulfillment evidence → closure رد می‌شود؛ (۳) obligation superseded شده اما predecessor و successor هر دو ACTIVE مانده‌اند → conflict. Probe چهارم due را زودتر می‌کند در حالی که notification history ثابت است تا نشان دهد risk باید از due evidence دوباره محاسبه شود.
15. Transfer: All-day Filing با Deadline اصلاح‌شده
یک filing obligation فقط due_date دارد و all-day است؛ پس timezone لحظه‌ای را به آن تحمیل نکن. بعد پیام معتبر جدید deadline را تغییر می‌دهد. record اول را نگه دار و SUPERSEDED کن، record دوم را با due date جدید ACTIVE نگه دار و نشان بده فقط یک active successor داریم. baseline decision را کپی نکن؛ semantics، risk و state را از evidence جدید بساز.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
PLN-005-AS1 application
Build Obligation Lifecycle & Deadline-Risk Register v1 from the supplied synthetic messages and planning records.
PLN-005-AS2 diagnosis
Diagnose a timed obligation whose timezone was removed and explain why deadline risk cannot be asserted definitively.
PLN-005-AS3 decision
Decide whether a COMPLETED state is defensible when fulfillment evidence is missing, and provide a finite recheck path.
PLN-005-AS4 transfer
Rebuild the register for an all-day filing obligation that is later superseded by a revised deadline, preserving both records with one active successor.
ملاک‌های ارزیابی (rubric)
Critical dimensions: exact source binding, owner/counterparty, explicit timed-versus-all-day due semantics, timezone completeness for timed values, distinct ACTIVE/BLOCKED/COMPLETED/CANCELED/SUPERSEDED states, bounded deadline risk, fulfillment evidence before completion, supersession history, finite recheck and changed-context transfer. A submission fails if reminder/transport success becomes completion, timezone ambiguity is silently resolved, or both predecessor and successor remain active after supersession.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
Build Obligation Lifecycle & Deadline-Risk Register v1 from the supplied synthetic cases. Bind each commitment to source evidence, distinguish timed from all-day due semantics, preserve blockers and lifecycle history, derive bounded risk only from interpretable due evidence, and require fulfillment evidence or an authorized closure reason before closure. The starter intentionally contains no expected final states.