Contributor و Editorial Governance

صفحه دیروز تأیید شده؛ آیا Revision امروز هم تأیید شده است؟

یک contributor صفحهٔ درس را می‌نویسد. editor، Revision R7 را تأیید می‌کند. بعد contributor پاسخ assessment و متن evidence را تغییر می‌دهد و R8 ساخته می‌شود، اما صف انتشار هنوز approval مربوط به R7 را حمل می‌کند. اگر سامانه فقط approved=true ذخیره کند، دیگر نمی‌تواند ثابت کند approval دقیقاً به کدام نسخه تعلق داشته است.

در این درس Contributor Editorial Governance Matrix & Revision Approval Ledger v1 را می‌سازیم. این artifact، هویت محتوا و Revision، Change Hash، contributor/reviewer/editor/publisher، محدودهٔ authority، تعداد review، owner review، conflict/recusal، exception، provenance، comment، publish gate، rollback و audit event را جدا نگه می‌دارد.

قاعدهٔ مرکزی: اجازهٔ contribution همان اجازهٔ approval نیست؛ approval یک Revision به Revision بعدی منتقل نمی‌شود؛ و انتشار یک تصمیم انسانیِ محدود و قابل‌ممیزی بر پایهٔ evidence قابل‌مشاهده است.

برای: مهندسان learning platform، طراحان CMS، تیم editorial operations، QA و صاحبان governance. نه برای: دادن authority پنهان، واگذاری approval به AI، انتقال خودکار approval میان Revisionهای material یا تبدیل مکانیک GitHub به authority محصول MAKNOW.

جایگاه درس و مرز مالکیت

MKN-021 فقط مالک Contributor و Editorial Governance است. prerequisite فریز‌شدهٔ آن MKN-001 است. MKN-020 مالک Learning/Product Analytics Event Taxonomy و MKN-022 مالک Web Push و Email Notification Delivery است؛ این درس outcome آن‌ها را جذب نمی‌کند.

مسیر foundation با field map نقش/قابلیت و یک stale-approval case شروع می‌شود. مسیر repair اولین dimension خراب را جدا می‌کند و فقط همان gate را دوباره اجرا می‌کند. مسیر experienced باید materiality، recusal، exception و rollback را بدون تبدیل آن‌ها به یک trust score دفاع کند.

Checkpointها: F1 مرز درس و یک non-goal؛ F2 تشخیص این‌که چرا approval مربوط به R7 نمی‌تواند R8 را مجاز کند؛ F3 بازمحاسبهٔ authority وقتی volunteer contributor به paid editor تبدیل می‌شود، بدون انتقال self-review privilege یا approval قبلی.

مدل ذهنی: contribution → هویت Revision → reviewer assignment → conflict check → review وابسته به Revision → publish gate

جریان را این‌طور ببینید:

draft contribution → content/revision/change hashes → capability + object scope → reviewer assignment → conflict/recusal → revision-bound review → editorial approval → publisher gate → publish/hold → rollback/audit

هر تغییر material بعد از review یک review object جدید می‌سازد. history می‌تواند باقی بماند، اما authority نباید بی‌صدا به Revision جدید منتقل شود. approval قدیمی evidence دربارهٔ entity قدیمی است؛ property جادویی نام document نیست.

Governance record باید ledger از factهای typed باشد، نه یک approved mutable. Revision می‌تواند DRAFT، REVIEW_REQUIRED، HOLD_STALE_APPROVAL، HOLD_CONFLICT_REVIEW، HOLD_EXCEPTION_EXPIRED یا PUBLISH_REVIEW_REQUIRED باشد. state باید دلیل توقف gate را نشان دهد.

قرارداد پایه: هر تصمیم authority را به object و Revision دقیق متصل کن

۲۴ dimension فریز‌شده عبارت‌اند از: content_object_id، revision_hash، change_set_hash، contributor_ref، reviewer_ref، editor_ref، publisher_ref، authority_scope، approval_state، approval_revision، stale_approval، required_review_count، owner_review_required، conflict_of_interest_state، recusal_state، exception_ref، exception_expiry، provenance_entity، provenance_activity، provenance_agent، review_comment_ref، publish_gate_state، rollback_ref و audit_event_id.

Invariantهای حداقلی:

1. capability هم به role و هم به object/object class وابسته است؛ role name به‌تنهایی authority نیست.
2. approval_revision باید با Revision واردشده به publish gate یکی باشد؛ material change approval قبلی را stale یا invalid می‌کند.
3. contributor نباید بی‌صدا تنها reviewer تغییر خودش شود. conflict و recusal state درجه‌اول هستند.
4. required review count و owner-review از evidence فعلی بررسی می‌شوند، نه از سابقه یا reputation.
5. exception باید صریح، محدود، attributable و دارای expiry باشد. exception منقضی authority نیست.
6. provenance باید entity، activity و agent را ثبت کند. evidence مفقود با حدس پر نمی‌شود.
7. publish gate evidence review را mutate نمی‌کند؛ فقط آن را evaluate می‌کند. rollback و audit بعد از انتشار هم باقی می‌مانند.
8. AI می‌تواند evidence را مرتب یا validate کند، اما حق grant کردن approval، recusal، exception یا publication ندارد.

توضیح عمیق: Provenance و Review Control دو نیمهٔ متفاوت مسئله‌اند

W3C PROV. خانوادهٔ PROV، provenance را با entity، activity و agent مدل می‌کند. در این درس R8 یک entity است، edit یا review یک activity و contributor/reviewer یک agent. relationهای attribution و derivation کمک می‌کنند بفهمیم artifact چگونه ساخته و تغییر کرده است. PROV نقش‌های editorial MAKNOW، حداقل approval یا publisher را تعیین نمی‌کند.

GitHub ruleset/review controls. مستندات جاری GitHub همچنان required approval، code-owner review، approval از شخصی غیر از آخرین pusher و dismiss کردن stale approval پس از تغییر diff را پشتیبانی می‌کند. این الگو نشان می‌دهد موضوع approval، وضعیت مشخصی از change است و تغییر بعدی می‌تواند approval را stale کند. GitHub فقط implementation example است، نه constitution محصول MAKNOW.

Inference MAKNOW. از ترکیب provenance و review control یک inference قوی داریم: approval باید revision-scoped و audit-friendly باشد. اگر evidence reviewed به شکل material تغییر کرد، approval قبلی history می‌ماند اما authority Revision جدید نیست.

Design MAKNOW. نام roleها، capability matrix، object scope، conflict categories، recusal procedure، required-review count، exception approver/duration، material-change rule، publisher و rollback policy همگی local design هستند.

مثال‌های حل‌شده

مثال A — R7 تأیید شده، اما assessment/evidence در R8 تغییر کرده

برای COURSE-PAGE-17، revision_hash=R8-HASH است ولی ledger می‌گوید approval_revision=R7-HASH. Change set مربوط به R8 شامل تغییر پاسخ assessment و evidence text است. مستقل از این‌که چه کسی edit را انجام داده، entity مورد تأیید دیگر current entity نیست.

نتیجهٔ درست: stale_approval=true و HOLD_STALE_APPROVAL. review comment و provenance مربوط به R7 حفظ می‌شود؛ برای R8 review activity جدید ساخته می‌شود؛ history overwrite نمی‌شود.

مثال B — contributor تنها reviewer است و conflict فعال است

AGENT-A روی درس خودش edit می‌کند و تنها reviewer هم خودش است. conflict_of_interest_state=ACTIVE، recusal_state=NOT_RECUSED و exception معتبر وجود ندارد. reputation بالا یا سابقهٔ طولانی conflict را از بین نمی‌برد.

نتیجهٔ درست: HOLD_CONFLICT_REVIEW. reviewer واجدشرایط دیگری route می‌شود، recusal ثبت می‌شود و attribution contributor باقی می‌ماند. اگر policy محلی emergency exception بدهد، authority، expiry و audit event آن باید explicit باشد.

مثال C — Revision فعلی به publisher gate می‌رسد

R8 review مستقل و current دارد، review count کامل است، owner review در صورت نیاز ثبت شده، conflict clear است، exception stale وجود ندارد، provenance کامل است و rollback/audit reference وجود دارد. سیستم فقط تا PUBLISH_REVIEW_REQUIRED پیش می‌رود.

این state عمداً auto-publish نیست. deterministic gate فقط اثبات می‌کند evidence package برای تصمیم publisher مجاز کافی است؛ خود publisher را جعل نمی‌کند.

Failure modeهای رایج

• approved=true بدون approval_revision: معلوم نیست چه چیزی review شده است.
• role به‌عنوان authority جهانی: ارتقا به editor برای همهٔ objectها به‌صورت ضمنی authority می‌سازد.
• self-review پنهان: contributor و reviewer یک agent هستند و conflict اصلاً ثبت نشده.
• approval بعد از material edit زنده می‌ماند: UI commentهای R7 را دارد و R8 را اشتباه approved نشان می‌دهد.
• exception منقضی فعال می‌ماند: bypass موقت به authority دائمی تبدیل می‌شود.
• review count بدون eligibility: تعداد approval کامل است اما reviewerها scope لازم ندارند.
• owner review حذف می‌شود: object حساس با general approval عبور می‌کند.
• provenance فقط username است: رابطهٔ entity/activity/agent و derivation قابل بازسازی نیست.
• AI recommendation به approval تبدیل می‌شود: مدل «safe» می‌گوید و سامانه آن را human authority ثبت می‌کند.
• rollback وجود ندارد: audit فقط تا زمانی کار می‌کند که هیچ خطایی رخ ندهد.

Alternativeها و trade-offها

Invalidate کردن همهٔ approvalها بعد از هر تغییر در برابر materiality rule. روش اول ساده‌تر و محافظه‌کارتر است ولی review load بالا می‌رود. materiality classifier کارآمدتر است ولی باید deterministic field، conservative default و escalation برای uncertainty داشته باشد.

Strict separation of duties در برابر bounded exception. جداسازی سخت authority را شفاف می‌کند اما تیم کوچک را در incident متوقف می‌کند. exception فقط وقتی operable و ایمن است که محدود، attributed، time-bounded و برای reviewer بعدی قابل‌دیدن باشد.

Publisher مرکزی در برابر distributed publishing. Publisher مرکزی accountability را ساده می‌کند؛ distributed right صف را کوتاه می‌کند. در حالت distributed، object scope و capability snapshot باید explicit باشند.

Mutable status در برابر append-oriented ledger. status mutable query ساده دارد ولی علت تغییر state را پاک می‌کند. ledger append-oriented history review، recusal، exception و rollback را حفظ می‌کند. projection فعلی می‌تواند از history ساخته شود.

پل experienced: Editorial Governance یعنی authorization روی versioned evidence

در سیستم بالغ، governance فقط permissionهای CMS نیست. role service قابلیت بالقوه را می‌دهد؛ object policy scope را محدود می‌کند؛ revision ledger مشخص می‌کند کدام bytes/semantic revision review شده؛ provenance agent/activity/entity را متصل می‌کند؛ conflict state reviewer eligibility را تغییر می‌دهد؛ و publisher gate این factها را بدون rewrite کردنشان ترکیب می‌کند.

Observability بهتر باید eventهای جداگانه برای contribution created، revision changed، reviewer assigned، conflict detected، recusal completed، review submitted، approval staled، exception granted/expired، owner review satisfied، publish gate evaluated، publication authorized/executed و rollback داشته باشد. «تعداد محتوای approved» به‌تنهایی governance metric ضعیفی است.

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

Guided. در lab://MKN-021/MKN-021-LAB1 از baseline stale revision شروع کن. Matrix را از fieldهای visible پر کن، اولین invariant مسدودکننده را مشخص کن و توضیح بده چرا حفظ R7 approval به‌عنوان provenance با استفاده از آن برای authorize کردن R8 فرق دارد.

بعد fixture را repair کن: approval را به Revision فعلی bind کن، review count و owner review را کامل کن، conflict/recusal و provenance را بررسی کن. نتیجه باید فقط تا PUBLISH_REVIEW_REQUIRED برود، نه PUBLISHED.

Independent. سه mutation را بدون کپی جواب baseline بررسی کن: self-review با conflict فعال، exception منقضی و role change بدون capability recomputation. برای هرکدام field نامعتبر، state نهایی، minimum repair و evidence لازم برای audit trail را بنویس.

Experienced extension. یک material-change taxonomy پیشنهاد بده: یک case که همیشه approval را invalidate کند، یک case که شاید approval را حفظ کند و یک case uncertain که review لازم دارد. حتماً local-design بودن taxonomy را شفاف نگه دار.

Verification و evidence

Artifact اصلی MKN-021-T1 — Contributor Editorial Governance Matrix & Revision Approval Ledger v1 است. سه scenario دارد: R8 با stale approval، Revision repaired و transfer ناشی از role change. Lab همین evidence را در JSON اجرا می‌کند.

Verification باید ثابت کند:

• هر ۲۴ critical dimension فریز‌شده visible است؛
• approval_revision با revision_hash فعلی مقایسه می‌شود؛
• stale approval، conflict/recusal، exception expiry، review count و owner-review مستقل بررسی می‌شوند؛
• provenance entity/activity/agent برای positive gate وجود دارد؛
• rollback و audit event قبل از publisher decision ثبت‌اند؛
• missing evidence به HOLD یا REVIEW_REQUIRED می‌رود، نه authority اختراعی؛
• transfer، capability را از role و scope فعلی بازسازی می‌کند و baseline label oracle نیست.

Oracle آزمایش deterministic است: frozen evidence contract + fixtureهای visible؛ نه chain-of-thought مدل.

Assessment و gate انتقال

S1 — retrieval: مرز Contributor و Editorial Governance و یک non-goal را توضیح بده. S2 — application: Matrix را برای baseline synthetic fixture بساز و state محدود را دفاع کن. S3 — diagnosis: بعد از approval یک assessment field material تغییر کرده اما approval_revision ثابت مانده؛ field/state invalid، consequence و minimum repair را مشخص کن. S4 — transfer: volunteer contributor به paid editor تبدیل شده است. authority را از role فعلی، object scope، conflict state و revision ownership بازسازی کن و approval/self-review privilege قدیمی را carry نکن.

Pass فقط وقتی است که identity/contract درست، evidence binding دقیق، negative evidence visible، decision محدود و transfer واقعاً recomputed باشد. reviewer انسانی باید بتواند بدون hidden model reasoning نتیجه را از evidence package بازسازی کند.

منابع، freshness و مرز authority

FACT — W3C PROV: مدل provenance حول entity/activity/agent، attribution و derivation. در 2026-09-13 دوباره بررسی شد. PROV authority نقش‌های editorial MAKNOW نیست.

FACT — GitHub review/ruleset controls: مستندات فعلی required approval، code-owner review و stale-approval dismissal در اثر تغییر reviewed diff را نگه داشته‌اند. در 2026-09-13 دوباره بررسی شد و چون vendor behavior evolving است باید طبق freshness schedule دوباره چک شود.

INFERENCE — revision-scoped approval: MAKNOW از provenance + review-control pattern نتیجه می‌گیرد approval باید به Revision reviewed bind باشد و material change آن را stale کند؛ تعریف materiality local است.

DESIGN — capability matrix و publish gate: role، object scope، conflict taxonomy، recusal، review count، exception authority/expiry، publisher، rollback و state vocabulary local design هستند. تغییر منبع خارجی accepted package را بی‌صدا mutate نمی‌کند.