Assignment Workflow

مسئله واقعی: «Assigned To» مسئولیت نیست

اگر یک کار در سیستم به نام یک نفر خورده، اعلان هم برایش ارسال شده و موعد تحویل هم دارد، هنوز نمی‌توان گفت او مسئول نسخه فعلی کار است. باید بدانیم چه کسی با چه اختیاری assignment را ساخته، assignee دقیقاً چه نقش و scopeای را پذیرفته، کدام plan/version معتبر بوده و در handoff یا reassignment چه چیزی منتقل شده است. خروجی این درس Assignment State and Responsibility Ledger v1 است.

مرز مالکیت این درس

COM-023 فقط workflow انتساب و مسئولیت را مالک است. کیفیت vetting یا test job متعلق به COM-022 است؛ هویت و حقوق assetهای رسانه‌ای متعلق به COM-024 است. assignment authority نیز با review approval و publication authority یکی نیست. این درس هیچ استخدام واقعی، تغییر تیم production، انتشار یا mutation بیرونی انجام نمی‌دهد.

مدل ذهنی: چهار چیز را جدا نگه دار

1. Work identity: assignment_id و work_item_id می‌گویند درباره کدام واحد کار حرف می‌زنیم.
2. Responsibility binding: assignee، role، assigner و assignment_authority مشخص می‌کنند چه کسی حق انتساب داشته و مسئولیت به چه کسی پیشنهاد شده است.
3. Version binding: plan_id/plan_version, input_refs و scope_version تعیین می‌کنند پذیرش دقیقاً برای چه نسخه‌ای بوده است.
4. Lifecycle evidence: acceptance، start، handoff، reassignment، submit، review و audit به‌صورت رویدادهای جدا ثبت می‌شوند.

اعلان یک پیام است؛ پذیرش یک رویداد مسئولیت است. تغییر فیلد assignee یک mutation UI است؛ handoff یک مرز evidence است.

FACT، INFERENCE و DESIGN را جدا کن

FACT: PROV-O یک Recommendation رسمی W3C است و provenance را با Entity، Activity و Agent مدل می‌کند. Association و delegation برای نسبت‌دادن مسئولیت/نمایندگی وجود دارند و qualified association می‌تواند role و plan را هم ثبت کند. INFERENCE: برای audit عملی بهتر است acceptance و handoff event باشند، نه اینکه فقط آخرین مقدار Assigned To نگه داشته شود. DESIGN: stateهای ACCEPTED, DECLINED, IN_PROGRESS, HANDOFF, REASSIGNED, SUBMITTED و fail-closed stateهای HOLD/BLOCKED/DISPUTED طراحی MAKNOW هستند؛ W3C آن‌ها را تجویز نکرده است.

قرارداد ۲۱بُعدی Assignment Ledger

1) assignment_id و work_item_id

assignment یک lifecycle مستقل دارد. reassign کردن همان work item الزاماً به معنی ساخت work item جدید نیست، ولی history assignment نباید overwrite شود.

2) assignee، role، assigner و authority

assignee_id می‌گوید چه کسی، assignee_role می‌گوید در چه نقشی، assigner_id می‌گوید چه کسی action را آغاز کرده و assignment_authority ثابت می‌کند آن actor حق چنین کاری داشته است. reviewer approval جای assignment authority را نمی‌گیرد.

3) plan/input/scope version

پذیرش بدون version binding مبهم است. اگر plan از v3 به v4 عوض شود، پذیرش v3 خودکار به v4 سرایت نمی‌کند. حداقل باید delta روشن و re-acknowledgement ثبت شود.

4) acceptance جدا از notification

Delivery receipt ایمیل/Push/Slack فقط ثابت می‌کند پیام تحویل شده؛ acceptance_state=ACCEPTED باید evidence خودش را داشته باشد. DECLINED نیز state معتبر است و نباید به failure مخفی تبدیل شود.

5) workflow state رویدادمحور

IN_PROGRESS باید بعد از پذیرش معتبر و start ثبت شود. HANDOFF مرز انتقال است. REASSIGNED فقط وقتی bounded است که handoff traceable باشد و assignee جدید scope فعلی را بپذیرد. SUBMITTED بدون output_ref معتبر نیست.

6) approval از assignment جداست

reviewer_id و approval_state درباره review هستند. آن‌ها نه assignment authority ایجاد می‌کنند و نه publication authority را منتقل می‌کنند. این تفکیک جلوی خطای «reviewer تأیید کرد پس مسئولیت هم منتقل شد» را می‌گیرد.

7) audit/evidence append-only

audit_event_id و evidence_ref باید chain رویدادها را قابل بازسازی کنند. سابقه تکمیل‌شده در handoff حذف نمی‌شود؛ فقط مسئولیت آینده از یک boundary جدید شروع می‌شود.

مثال‌های کاری

۱. baseline معتبر → IN_PROGRESS

مدیر مجاز assignment را برای brief v3 می‌سازد، Creator A همان scope را ACCEPTED می‌کند و start event ثبت می‌شود. مسئولیت current scope فعال است.

۲. notification تحویل شده ولی acceptance نداریم → HOLD

UI اسم Creator A را نشان می‌دهد و اعلان deliver شده، اما acceptance event وجود ندارد. نتیجه success نیست.

۳. plan از v3 به v4 تغییر کرده بدون re-ack → HOLD

پذیرش v3 evidence خوبی است، اما برای scope جدید کافی نیست. باید delta و پذیرش نسخه جدید ثبت شود.

۴. reassignment بدون handoff → DISPUTED

Creator B در Assigned To جایگزین شده، ولی handoff_id و preservation evidence نداریم. مسئولیت گذشته و آینده قابل تفکیک نیست.

۵. reassignment صحیح → REASSIGNED

Creator A evidence تکمیل‌شده را تحویل می‌دهد، handoff event ثبت می‌شود، Creator B scope فعلی را می‌پذیرد. assignment responsibility منتقل می‌شود، اما review approval قبلی به B منتقل نمی‌شود.

۶. reviewer تأیید کرده ولی assigner authority ندارد → BLOCKED

Approval review هیچ اختیاری برای assign کردن ایجاد نمی‌کند.

failure modeهای رایج

• Assigned To را به‌عنوان accepted responsibility می‌گیریم.
• delivery notification را معادل acceptance می‌گیریم.
• plan/scope version را عوض می‌کنیم ولی acceptance قبلی را reuse می‌کنیم.
• reassignment را با overwrite فیلد assignee انجام می‌دهیم و handoff history را حذف می‌کنیم.
• completed evidence نفر قبلی را همراه reassignment دور می‌ریزیم.
• approval reviewer را assignment authority فرض می‌کنیم.
• assignment authority را publication authority فرض می‌کنیم.
• SUBMITTED را بدون output evidence صادر می‌کنیم.
• missing evidence را با «احتمالاً پذیرفته» پر می‌کنیم.

گزینه‌ها و trade-offها

Mutable current-row only: ساده و ارزان است، اما audit و handoff را خراب می‌کند. Event ledger + current projection: تاریخچه کامل دارد و current view هم سریع می‌ماند؛ هزینه مدل‌سازی بیشتر است، اما گزینه پیشنهادی این درس است. Full workflow engine: برای orchestration پیچیده مفید است، ولی برای اثبات این outcome لازم نیست. اول evidence contract را درست کن؛ بعد ابزار را انتخاب کن.

پل برای فرد باتجربه: ۱۴ سؤال critical

آیا assignment/work item identity روشن است؟ assignee و role صریح‌اند؟ authority assigner معتبر است؟ plan و version مشخص‌اند؟ scope version مشخص است؟ acceptance event برای همان scope وجود دارد؟ state با event evidence سازگار است؟ reassignment handoff دارد؟ output reference در submit حاضر است؟ audit event وجود دارد؟ evidence reference قابل‌ردیابی است؟ completed evidence حفظ شده؟ approval مستقل از assignment authority مانده؟ transfer verdict از baseline کپی نشده است؟

تمرین هدایت‌شده و مستقل

ابتدا fixture baseline را با جدول ۲۱بُعدی کامل کن و state را فقط از evidence بساز. سپس سه mutation را اجرا کن: notification-only، plan version change بدون re-ack، و reassignment بدون handoff. در مرحله مستقل، transfer اصلی را اجرا کن: specialist در میانه کار به دلیل ظرفیت عوض می‌شود. مشخص کن چه evidenceای حفظ می‌شود، چه مسئولیتی منتقل می‌شود و چه approvalهایی منتقل نمی‌شوند.

evidence قابل‌قبول

حداقل evidence قابل‌قبول شامل assignment/work item identity، assignee/role، assignment authority، plan/version، scope version، acceptance state، workflow state، handoff/output در صورت نیاز، audit event و evidence reference است. هر تصمیم باید از رکوردهای visible قابل بازسازی باشد؛ hidden reasoning یا حدس جای evidence را نمی‌گیرد.

Assessment و transfer

برای قبولی باید چهار چیز را نشان دهی: مرز COM-023، baseline ledger کامل، diagnosis یک mutation، و transfer reassignment. در transfer، evidence تکمیل‌شده قبل از handoff حفظ می‌شود؛ assignee جدید باید scope فعلی را بپذیرد؛ review/publication approval به‌صورت خودکار منتقل نمی‌شود. اگر هرکدام از این شروط غایب است، success state ممنوع است.

منابع و freshness

• W3C PROV-O: The PROV Ontology — Recommendation, 30 April 2013. در 2026-09-15 دوباره بررسی شد؛ Recommendation پایدار است و Entity/Activity/Agent، Association، Role، Plan و Delegation را پوشش می‌دهد. https://www.w3.org/TR/prov-o/
• state vocabulary و authority split این درس MAKNOW DESIGN است، نه الزام W3C.
• Claimهای evolving این درس تا 2026-12-31 یا زودتر در صورت تغییر materially relevant دوباره بررسی می‌شوند.