Content Workflow States

1) چرا «Draft / Done / Published» برای workflow کافی نیست؟

در تیم‌های محتوا، برچسب‌هایی مثل Draft، Done و Published سریع و آشنا هستند؛ اما یک مشکل مهم دارند: به‌تنهایی نمی‌گویند چه کسی اجازه‌ی تغییر state را دارد، چه evidence لازم است، rejection به کجا برمی‌گردد و automation تا کجا حق حرکت دارد. اگر job هوش مصنوعی تمام شود و سیستم مستقیماً محتوا را Published کند، «موفق شدن task» با «اجازه‌ی انتشار» اشتباه گرفته شده است.

در این درس Content Workflow State Machine v1 را می‌سازیم: یک state machine محدود، صریح و قابل‌ممیزی که transitionها، actor، permission، evidence، human gate، rework و audit event را از هم جدا می‌کند.

قانون مرکزی: پایان یک task مساوی با مجوز عبور از state نیست؛ هر transition باید authority و evidence خودش را داشته باشد.

2) مرز درس و چیزی که مالک آن نیستیم

COM-017 مالک Content Workflow States است. COM-016 درباره‌ی Asset Provenance است و COM-018 مالک Client Approval States و Revision Branching. پس این درس branch approval مشتری را از نو طراحی نمی‌کند و provenance دارایی را هم جذب نمی‌کند.

همچنین این درس هیچ انتشار زنده، billing change، tenant mutation یا authority حقوقی ایجاد نمی‌کند. خروجی فقط یک مدل evidence-backed و آزمایشگاه synthetic آفلاین است.

3) مدل ذهنی: State → Transition → Actor → Permission → Evidence → Audit

برای هر transition باید بتوانیم حداقل این پرسش‌ها را جواب بدهیم: از چه stateی به چه stateی می‌رویم؟ transition چه شناسه‌ای دارد؟ actor چه roleی دارد؟ permission واقعاً grant شده؟ چه evidence لازم است؟ آیا human approval لازم است؟ اگر رد شد، rework به کجا برمی‌گردد؟ و کدام audit event این تغییر را ثبت کرده است؟

اگر evidence حیاتی وجود ندارد، سیستم نباید با حدس به success برسد. HOLD و BLOCKED stateهای معتبر هستند، نه خطای UX.

4) Fact بیرونی را از طراحی MAKNOW جدا کن

مستندات فعلی Contentful نشان می‌دهد Workflows می‌تواند فرآیند تولید محتوا را به stepهای مشخص تقسیم کند، تغییر step را به permission مرتبط کند و actionهایی مثل notification، task و AI action را روی workflow اجرا کند. همچنین برخی stepها می‌توانند به‌صورت خودکار complete شوند. این‌ها FACTهای محصول هستند.

اما از این factها نتیجه نمی‌شود که automation باید حق approval یا publication داشته باشد. محل human gate، نام stateها و transition matrix این درس DESIGN داخلی MAKNOW هستند.

5) State با task status فرق دارد

current_state باید معنی عملیاتی داشته باشد، نه صرفاً گزارش یک job. در baseline این درس، مسیر اصلی چنین است:

INTAKE → DRAFT → REVIEW → APPROVAL → PUBLISH_READY → PUBLISHED

و مسیر اصلاح:

REVIEW → REWORK → REVIEW

اگر یک AI rewrite با موفقیت تمام شد، نهایتاً می‌تواند evidence را آماده کند یا آیتم را برای review route کند؛ success آن job به‌خودی‌خود APPROVAL یا PUBLISHED نیست.

6) Transition contract را صریح بنویس

هر transition باید transition_id، from_state و to_state داشته باشد. transitionهایی که در matrix تعریف نشده‌اند باید BLOCKED_INVALID_TRANSITION شوند.

این قانون جلوی shortcutهایی مثل DONE → PUBLISHED را می‌گیرد؛ چون Done نه evidence publication است، نه state مجاز در این ماشین.

7) Role و Permission یکی نیستند

actor_role می‌گوید شخص چه نقشی دارد؛ permission_check می‌گوید در همین transition مشخص اجازه‌ی عمل دارد یا نه. یک Editor ممکن است حق edit داشته باشد ولی حق publish نداشته باشد.

پس حتی اگر role به‌نظر مناسب برسد، permission_check=DENIED باید transition را به BLOCKED_PERMISSION ببرد. UI access یا نام role جای permission evidence را نمی‌گیرد.

8) Human gate را از automation boundary جدا کن

در طراحی این درس، transition ورود به Approval و transition نهایی Publication human-authorized هستند. automation می‌تواند draft بسازد، validation اجرا کند، notification بفرستد یا کار را route کند؛ اما نباید بی‌صدا human gate را رد کند.

اگر automation_action مستقیماً approval transition را اجرا کند، نتیجه باید BLOCKED_AUTOMATION_AUTHORITY باشد، حتی اگر output فنی automation صحیح باشد.

9) Rejection باید مسیر برگشت واقعی داشته باشد

Review فقط success path نیست. اگر نتیجه REJECTED یا CHANGES_REQUESTED است، rejection_reason و rework_ref باید مشخص باشند تا آیتم به مسیر اصلاح برگردد.

حذف این مسیر باعث می‌شود workflow ظاهراً state داشته باشد اما failure قابل‌عمل نباشد. در این حالت state باید BLOCKED_TRACEABILITY شود تا rework evidence تکمیل شود.

10) Audit event بخشی از transition است

هر تغییر state باید audit_event_id و evidence_ref داشته باشد. اگر state عوض شده اما log فقط نوشته «job completed»، reviewer نمی‌تواند بفهمد چه کسی، با چه permission و بر اساس چه evidence تصمیم گرفته است.

Missing audit evidence نباید با success جایگزین شود؛ باید HOLD_MISSING_EVIDENCE باقی بماند.

11) Lab: هشت fixture و 48 assertion

Lab کاملاً آفلاین و synthetic است و credential یا tenant واقعی ندارد. هشت fixture داریم و برای هرکدام شش invariant deterministic بررسی می‌شود؛ در مجموع 48 assertion.

سناریوها شامل baseline approval، automation bypass، rejection بدون rework، DONE → PUBLISHED، audit gap، permission denial، publication کنترل‌شده و legal-review conditional هستند. هدف فقط سبزکردن baseline نیست؛ باید ببینی هر failure دقیقاً کدام contract را می‌شکند.

12) Transfer: Legal Review فقط جایی که لازم است

سناریوی انتقال می‌گوید برای یک content class خاص، Legal Review اجباری می‌شود؛ اما برای بقیه‌ی محتواها لازم نیست. طراحی ضعیف یا legal gate را برای همه حذف می‌کند، یا آن را روی همه‌ی محتواها تحمیل می‌کند.

طراحی درست یک شرط صریح دارد: اگر legal_review_required=true، ورود به Approval تا ثبت legal_review_passed=true متوقف می‌شود. برای content classهای دیگر همان مسیر عادی حفظ می‌شود. یعنی کنترل جدید scope دارد و workflow را بی‌دلیل سنگین نمی‌کند.

13) جمع‌بندی و معیار عبور

برای عبور از COM-017 باید بتوانی یک Content Workflow State Machine v1 بسازی که transition مجاز، actor، permission، required evidence، human gate، rejection/rework و audit event را صریح نگه دارد. همچنین باید shortcutهایی مثل automation approval، permission bypass و Done=Published را رد کنی.

Artifact نهایی این درس publication authority نیست؛ یک مدل محدود و قابل‌ممیزی برای تصمیم‌گیری است.

منابع و تازگی

• Contentful Help Center, Workflows — rechecked 2026-09-15.
• Contentful Help Center, Workflows steps management — rechecked 2026-09-15.
• Contentful Help Center, Workflow automations — rechecked 2026-09-15.
• human approval/publication gates، state vocabulary و conditional legal-review در این درس DESIGNهای MAKNOW هستند، نه الزام vendor.