معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۵ — Editorial Cell، SEO، QA، Approval و Onboarding · 251
Content QA Rubric
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Content QA Rubric». می‌تواند «Content QA Rubric» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خلاصهٔ درس
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Content QA Rubric».
می‌تواند «Content QA Rubric» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خروجی این درس
می‌تواند «Content QA Rubric» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
1) مسئله: میانگین خوب می‌تواند یک شکست جدی را پنهان کند
فرض کنید یک صفحهٔ خدمات از نظر لحن، نگارش و SEO امتیاز بالایی دارد؛ اما یک ادعای عملکردی بدون منبع است، label فرم به control متصل نیست و CTA با وعدهٔ اصلی صفحه هم‌خوانی ندارد. اگر همه‌چیز را در یک عدد میانگین کنیم، احتمال دارد صفحه «قبول» شود. QA حرفه‌ای باید برعکس عمل کند: هر بُعد مهم را مستقل ببیند و اجازه ندهد کیفیت بالا در یک بُعد، شکست بحرانی در بُعد دیگر را جبران کند.
2) مرز COM-010: Rubric کیفیت محتوا، نه طراحی SEO و نه lineage خروجی AI
مالک این درس Commercial Content QA Rubric v1 است. COM-009 مالک SEO Page Schema و intent-driven content است و COM-011 مالک Human Anchor + AI Variants. این درس تصمیم نمی‌گیرد صفحه چگونه تولید یا منتشر شود؛ فقط یک قرارداد قابل‌ممیزی برای بررسی نسخهٔ مشخص یک artifact می‌سازد.
3) مدل ذهنی: Artifact Version → Dimension Checks → Critical Blocker? → Repair/Retest → Final State
هر QA run باید به artifact_id و artifact_version دقیق وصل باشد. Dimensionها موازی بررسی می‌شوند. اگر یک blocker بحرانی باز باشد، میانگین یا «حس کلی خوب» حق عبور ندارد. بعد از repair، فقط dimensionهای متاثر دوباره تست می‌شوند؛ مگر اینکه نسخه یا شواهد حاکم تغییر کرده باشد.
4) FACT: Google people-first content یک چک‌لیست کمک‌کننده است، نه Rubric انتشار MAKNOW
راهنمای Google Search Central هنوز توصیه می‌کند محتوا اول برای انسان‌ها و برای کمک واقعی به هدف آن‌ها ساخته شود و پرسش‌هایی دربارهٔ usefulness، trust، expertise و رضایت خواننده مطرح می‌کند. این راهنما برای self-assessment مفید است، اما threshold و release state داخلی ما را تعیین نمی‌کند و تضمین رتبهٔ Search هم نیست.
5) FACT: Accessibility یک بُعد مستقل و قابل‌تست است
WCAG 2 مجموعه‌ای از success criterionهای قابل‌ارزیابی برای دسترس‌پذیری محتوای وب دارد و W3C استفاده از آخرین نسخه، یعنی WCAG 2.2، را تشویق می‌کند. بنابراین accessibility failure را نباید در «کیفیت نوشتار» حل کرد. در عین حال، عبور از WCAG به‌تنهایی factual accuracy، usefulness یا conversion quality را ثابت نمی‌کند.
6) قرارداد ۲۲ فیلدی: تصمیم بدون trace نباشد
هر ردیف QA باید context و evidence کافی داشته باشد: qa_run_id، artifact_id، artifact_version، reviewer، dimension، criticality، criterion، observable_evidence، state/score، severity، blocker، claim refs، accessibility/intent/helpfulness/duplication/conversion checks، repair، retest، final state و evidence_ref.
| qa_run_id | artifact_id | artifact_version | dimension_id | criticality | observable_evidence | score_or_state | severity | blocking_flag | final_state | evidence_ref |
|---|---|---|---|---|---|---|---|---|---|---|
| QA-100 | PAGE-42 | 7 | claim_support | CRITICAL | claim CLAIM-PERF-1 traces to SRC-77 | PASS | NONE | false | PASS | EVID-CLAIM-77 |
| QA-100 | PAGE-42 | 7 | accessibility_form_label | CRITICAL | label for=id verified in rendered DOM snapshot | PASS | NONE | false | PASS | EVID-A11Y-21 |
| QA-100 | PAGE-42 | 7 | intent_fit | CRITICAL | CTA requests the same consultation promised by page | PASS | NONE | false | PASS | EVID-INTENT-14 |
| QA-101 | PAGE-43 | 1 | duplication | CRITICAL | 0.91 similarity and audience intent unresolved | HOLD | MAJOR | true | HOLD_INTENT_DUPLICATION | EVID-DUP-31 |
نسخهٔ CSV/JSON شامل هر ۲۲ فیلد قرارداد است.
7) Criticality، Severity و Blocking Flag سه چیز متفاوت‌اند
criticality می‌گوید failure این dimension می‌تواند release را متوقف کند یا نه. severity شدت defect مشاهده‌شده است. blocking_flag نتیجهٔ اعمال policy روی آن defect است. اگر یک accessibility failure بحرانی را فقط با تغییر label به advisory بی‌خطر کنیم، Rubric قابل‌اعتماد نیست؛ state باید FAIL_SEVERITY_POLICY شود.
8) Claim Support و Accessibility غیرقابل‌جبران‌اند
یک ادعای factual/commercial بدون support روی dimension بحرانی، FAIL_CLAIM_SUPPORT است. یک failure بحرانی accessibility، FAIL_ACCESSIBILITY است. هیچ امتیاز Style، SEO یا Conversion نمی‌تواند این دو را به PASS تبدیل کند. Aggregate score اگر استفاده شود صرفاً خلاصه است، نه authority.
9) Helpfulness و Intent Fit را با SEO یکی نکنید
یک صفحه ممکن است keyword و structure عالی داشته باشد ولی کاربر بعد از خواندن هنوز نداند چه کاری باید انجام دهد. helpfulness_check می‌پرسد آیا artifact برای هدف واقعی مخاطب مفید است؛ intent_fit_check می‌پرسد آیا وعده، محتوا و next step با intent تعریف‌شده هم‌راستا هستند. این دو با ranking signal یا keyword density یکی نیستند.
10) Duplication را بدون Purpose و Audience قضاوت نکنید
شباهت زیاد همیشه به معنی defect نیست؛ اما اگر Variant جدید substantially duplicative باشد و دلیل جداگانه یا audience intent روشنی نداشته باشد، تصمیم امن HOLD_INTENT_DUPLICATION است. اگر intent روشن است ولی duplication باید کم شود، REVISE_DUPLICATION مناسب‌تر است. این distinction اجازه نمی‌دهد ابزار similarity به‌تنهایی authority پیدا کند.
11) Missing Evidence صفر نیست؛ HOLD است
اگر observable_evidence یا evidence_ref برای یک بُعد بحرانی خالی است، نباید حدس بزنیم و نباید آن را صفر بگذاریم تا میانگین محاسبه شود. state صحیح HOLD_MISSING_EVIDENCE است. Typed non-success state به تیم می‌گوید مشکل «fail شدن artifact» نیست؛ مشکل «نبودن شواهد کافی برای تصمیم» است.
12) Version Binding: PASS قدیمی روی Artifact جدید معتبر نیست
QA run به نسخهٔ دقیق artifact وصل است. اگر صفحه بعد از review تغییر کرد، کپی کردن PASS قبلی روی artifact_version جدید invalid است و HOLD_STALE_ARTIFACT می‌گیرد تا dimensionهای متاثر دوباره ارزیابی شوند. این قاعده جلوی approval-by-copy را می‌گیرد.
13) Repair Loop: کوچک‌ترین repair، کوچک‌ترین retest معتبر
برای هر defect، repair_action باید دقیق و محدود باشد و retest_result نشان دهد همان defect دوباره بررسی شده است. اگر فقط label فرم اصلاح شده، لازم نیست claim support دوباره از صفر بررسی شود؛ اما اگر claim متن تغییر کرده، claim-support و هر dimension وابسته باید rerun شود. Rubric خوب evidence را reset نمی‌کند؛ dependency را دنبال می‌کند.
14) Failure Modeها و state درست
- همهٔ critical gateها بسته، نسخه جاری، retestها PASS →
PASS - defect غیرcritical باز →
REVISE_ADVISORY - duplication قابل‌اصلاح با intent روشن →
REVISE_DUPLICATION - ادعای بحرانی بدون support →
FAIL_CLAIM_SUPPORT - accessibility بحرانی fail →
FAIL_ACCESSIBILITY - critical failure عمداً advisory شده →
FAIL_SEVERITY_POLICY - evidence بحرانی ناقص →
HOLD_MISSING_EVIDENCE - PASS متعلق به نسخهٔ قبلی →
HOLD_STALE_ARTIFACT - duplication زیاد + intent مبهم →
HOLD_INTENT_DUPLICATION
15) Lab و Transfer: فقط dimension متاثر را دوباره بسنجید
Lab هشت fixture آفلاین دارد و ۴۸ assertion deterministic اجرا می‌کند. در Transfer، claim و accessibility قبلاً repair شده‌اند، اما variant جدید هم substantially duplicative است و هم intent مبهم دارد. شما باید بدون reset کردن evidence سالم، فقط duplication و intent را rerun کنید و state نهایی را از روی شواهد visible تعیین کنید. این درس live publishing، legal approval یا Search ranking را ثابت نمی‌کند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
COM-010-S1 retrieval
What is the owned boundary of Content QA Rubric?
COM-010-S2 application
Build Commercial Content QA Rubric v1 for the baseline fixture.
COM-010-S3 diagnosis
A critical unsupported claim is averaged with strong style scores and marked PASS. Which rule is violated and what state follows?
COM-010-S4 transfer
Claims/accessibility now pass, but a new variant is substantially duplicative and intent is ambiguous. Recompute only affected dimensions.
ملاک‌های ارزیابی (rubric)
- Identity and version: QA run is bound to the exact artifact version.
- Evidence: each critical state has observable, traceable evidence or remains HOLD.
- Non-compensation: claim support and accessibility blockers cannot be averaged away.
- Severity policy: criticality, severity and blocking flag remain coherent.
- Intent/duplication: similarity is interpreted with audience purpose, not used as automatic authority.
- Repair/retest: the smallest valid repair is followed by targeted retest; unrelated evidence is preserved.
- Transfer: changed-context state is recomputed instead of copying the baseline decision.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
python run_checks.py را اجرا کنید. fixtureها کاملاً مصنوعی و آفلاین‌اند. هدف حفظ version binding، blockerهای بحرانی غیرقابل‌جبران، stateهای typed و repair/retest هدفمند است. هیچ شبکه، API key یا محتوای production استفاده نمی‌شود.