Cadence Envelope و توصیه «کمتر/هیچ»

1. مسئله واقعی: تقویم نباید به‌جای Evidence تصمیم بگیرد

فرض کنید تیم محتوا متعهد شده هر هفته پنج خروجی منتشر کند. این هفته فقط دو موضوع Audience Need روشن، Evidence آماده و Unique Value واقعی دارند؛ یک موضوع تقریباً تکرار مقاله قبلی است و دو Slot دیگر فقط به‌خاطر خالی‌بودن تقویم پیشنهاد شده‌اند. اگر «Slot موجود» را مساوی «باید منتشر کنیم» بگیریم، فشار تقویم به تولید کم‌ارزش تبدیل می‌شود. این درس Cadence Envelope & Publish-Defer Decision Matrix v1 را می‌سازد تا Frequency پیامد کیفیت و نیاز باشد، نه هدف ثابت.

2. مرز درس و Artifact مالک

خروجی این درس یک Matrix قابل Audit است که برای هر Slot یا Candidate حداقل audience_need، evidence_readiness، unique_value، redundancy، editorial_capacity، freshness_need، risk، provenance_ref و review_date را ثبت می‌کند و یکی از Stateهای PUBLISH، REDUCE، DEFER یا NONE را می‌دهد. Content Gap Detection متعلق به PLN-010 و Audience Drift متعلق به PLN-012 است؛ این درس آن دو Outcome را جذب نمی‌کند.

3. Cadence Envelope چیست؟

Cadence Envelope یک عدد جادویی مثل «سه پست در هفته» نیست. Envelope محدوده‌ای است که در آن تیم فقط وقتی Publish می‌کند که Evidence، User Value و Capacity هم‌زمان حداقل لازم را داشته باشند. ممکن است Envelope یک هفته 3 خروجی و هفته بعد 1 یا حتی 0 باشد. Exact Band وابسته به Portfolio است و این درس Threshold جهانی اختراع نمی‌کند.

4. Evidence Readiness قبل از Calendar Priority

evidence_readiness باید پیش از فشار Calendar بسته شود. اگر Source، Example، Review یا Data لازم هنوز آماده نیست، اولویت بالای تقویم نمی‌تواند Evidence غایب را جبران کند. در Fixture این درس، حذف Evidence Readiness در حالی که Calendar Priority بالا باقی مانده است باید به REVIEW_REQUIRED یا DEFER ختم شود، نه Publish خوش‌بینانه.

5. Google و مرز Freshness

راهنمای فعلی Google Search می‌گوید افزودن حجم زیادی Content صرفاً با این تصور که سایت را «تازه» نشان می‌دهد، رویکرد people-first توصیه‌شده نیست [GOOGLE-HELPFUL]. این Source هیچ Cadence جهانی تجویز نمی‌کند؛ فقط یک Boundary مهم می‌دهد: Freshness ظاهری به‌تنهایی Reason کافی برای تولید بیشتر نیست.

6. Scaled Content Abuse یک هشدار کیفیت است، نه مدل تقویم

Spam Policies فعلی Google، scaled content abuse را تولید صفحات زیاد عمدتاً برای دستکاری Ranking و نه کمک به Users تعریف می‌کند [GOOGLE-SPAM]. این Policy مدل کامل Editorial Planning نیست، اما نشان می‌دهد «حجم بیشتر» بدون Added Value می‌تواند ضد هدف کیفیت باشد. MAKNOW از این Fact فقط به‌عنوان Guardrail استفاده می‌کند.

7. Audience Need و Unique Value را جدا ببند

audience_need می‌گوید آیا مسئله فعلی ارزش پاسخ‌دادن دارد؛ unique_value می‌گوید آیا Candidate چیزی معنادار فراتر از موجودی فعلی اضافه می‌کند. Need بالا با Value پایین هنوز Publish مجاز نمی‌سازد. اگر مقاله جدید فقط عنوان دیگری برای محتوای موجود باشد، redundancy بالا و unique_value پایین باید NONE بدهد.

8. Redundancy Gate جلوی «پرکردن Slot» را می‌گیرد

وجود Slot خالی Evidence نیست. Matrix باید Similar Coverage، Existing Canonical Piece و Overlap را بررسی کند. اگر Candidate همان سؤال را با تغییر سطحی تکرار کند، Decision باید NONE یا Merge/Improve خارج از این Matrix باشد؛ ساخت URL یا Article جدید فقط برای رسیدن به quota رد می‌شود.

9. Capacity یک Guardrail واقعی است

editorial_capacity باید شامل Research، Authoring، Review، QA و Update Budget باشد، نه فقط تعداد Writer. اگر quota برابر 5 است اما Reviewer فقط 2 خروجی را با کیفیت لازم می‌تواند ببندد، Cadence باید REDUCE شود. ثابت نگه‌داشتن quota و فشار بیشتر به Reviewer یک Failure Probe صریح این درس است.

10. Freshness Need با «تازه‌سازی مصنوعی» فرق دارد

بعضی محتواها واقعاً زمان‌حساس‌اند: Release Note، Policy Change یا Data Update. freshness_need برای این موارد است. اما تغییر تاریخ، بازنویسی سطحی یا تولید نسخه‌های مشابه صرفاً برای حس Freshness نباید Publish Trigger شود. Freshness باید به یک Change یا User Need قابل Trace متصل باشد.

11. چهار State اصلی: PUBLISH / REDUCE / DEFER / NONE

PUBLISH یعنی Candidate از Gateهای Value، Evidence، Capacity و Risk عبور کرده است. REDUCE یعنی Demand یا Ideas وجود دارد اما Capacity اجازه quota فعلی را نمی‌دهد. DEFER یعنی Value ممکن است واقعی باشد ولی Evidence، Review، Freshness Window یا Risk هنوز بسته نشده است. NONE یعنی اکنون خروجی جدید ارزش کافی ندارد یا Redundant است. «هیچ» یک نتیجه معتبر است، نه شکست Planner.

12. Stateهای عدم قطعیت را حذف نکن

در کنار چهار Decision اصلی، Contract باید UNKNOWN، INSUFFICIENT_DATA، REVIEW_REQUIRED، REJECTED یا DO_NOT_USE را در جای لازم حفظ کند. اگر Provenance وجود ندارد، Decision قابل Audit نیست. اگر Evidence Ready نامشخص است، سیستم نباید با حدس PUBLISH بسازد. یک Interface تمیز نباید uncertainty واقعی را پنهان کند.

13. مثال کارشده: quota پنج‌تایی با فقط دو Candidate معتبر

Team پنج Slot دارد. Candidate A و B Audience Need بالا، Evidence آماده، Unique Value بالا و Risk پایین دارند؛ هر دو PUBLISH می‌شوند. Candidate C پوشش موجود را تکرار می‌کند و NONE می‌گیرد. Candidate D Evidence ناقص دارد و DEFER می‌شود. Candidate E فقط به‌خاطر Empty Slot آمده و Need/Value کافی ندارد؛ NONE. نتیجه Envelope این هفته دو خروجی است، نه پنج.

14. Negative Caseها و Failure Probeهای قطعی

چهار Shortcut عمداً رد می‌شوند: 1) Force every empty slot to PUBLISH → شکست Redundancy/Value Gate؛ 2) Duplicate existing article with a new title → NONE; 3) Reduce reviewer capacity while keeping same quota → REDUCE; 4) Remove evidence readiness but keep calendar priority high → REVIEW_REQUIRED یا DEFER. Missing Provenance نیز REJECTED است و Stale Evidence باید Review Date محدود داشته باشد.

15. Transfer: Release Notes با رویدادهای نامنظم

اکنون همین Contract را به Release Notes منتقل کنید؛ جایی که Update مهم ممکن است دو هفته پشت‌سرهم برسد و بعد سه هفته هیچ تغییر معناداری نباشد. Envelope باید با Evidence جدید محاسبه شود. هفته بدون Update واقعی می‌تواند NONE باشد و نباید Filler Note برای حفظ quota ساخته شود. Transfer زمانی موفق است که Contract ثابت بماند ولی Frequency از Context و Evidence جدید دوباره محاسبه شود.