معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۵ — Editorial Cell، SEO، QA، Approval و Onboarding · 247
Multi-model Editorial Cell
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Multi-model Editorial Cell». می‌تواند «Multi-model Editorial Cell» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خلاصهٔ درس
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Multi-model Editorial Cell».
می‌تواند «Multi-model Editorial Cell» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خروجی این درس
می‌تواند «Multi-model Editorial Cell» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
پیش‌نیازها
1) مسئله‌ای که این درس حل می‌کند
چندمدلی‌کردن یک workflow به‌خودی‌خود آن را قابل‌اعتماد نمی‌کند. اگر RESEARCH، DRAFT، VERIFY و EDIT فقط زنجیره‌ای از promptها باشند، خروجی نهایی می‌تواند بسیار روان باشد اما هیچ‌کس نتواند نشان دهد هر claim از کدام source bundle آمده، کدام مدل آن را تغییر داده و اعتراض verifier چگونه حل شده است.
2) مرز دقیق COM-006
مالک این درس Editorial Cell Orchestration Contract v1 است. این درس انتخاب بهترین provider برای هر task را مالک نیست؛ آن موضوع COM-007 است. همچنین niche/intent research متعلق به COM-005 است. اینجا سؤال اصلی این است: «اگر چند مدل در یک سلول تحریریه کار می‌کنند، چگونه handoff و release را قابل‌ردیابی و قابل‌تکرار نگه داریم؟»
3) Fact: model identity بخشی از dependency است
کاتالوگ فعلی OpenAI مدل‌های مشخص با model ID و تفاوت‌های capability/selection را منتشر می‌کند. پس ثبت صرفِ «OpenAI» یا «AI writer» برای replay کافی نیست. model_provider و model_id باید کنار artifact همان stage ثبت شوند.
4) Fact: version/variant در Gemini هم صریح است
مستندات Gemini چند model variant و الگوهای version مانند stable، preview، latest و experimental را از هم جدا می‌کند. بنابراین alias یا نام خانواده به‌تنهایی provenance کامل نیست؛ stage باید آن model identity را که واقعاً اجرا شده ثبت کند.
5) چند مدل یعنی چند مسئولیت، نه چند رأی
در این طراحی پنج role جدا داریم: RESEARCH → DRAFT → VERIFY → EDIT → APPROVE. خروجی VERIFY «یک رأی دیگر» نیست؛ یک review result با artifact version مشخص است. اگر EDIT آن artifact را تغییر دهد، اعتراض verifier باید disposition شود، نه اینکه با rewrite ناپدید شود.
6) Stage contract چیست؟
برای هر stage چهار چیز را قبل از اجرا قفل کنید: ورودی مجاز، خروجی مورد انتظار، evidenceهایی که باید حفظ شوند و حالت‌های failure. stage_contract جلوی این را می‌گیرد که مثلاً EDIT ناگهان منبع جدید بسازد یا APPROVE خودش متن را بازنویسی کند.
7) Handoff باید versioned باشد
هر فلش در workflow باید input_artifact_id و output_artifact_id داشته باشد. اگر DRAFT نسخه draft-v3 را به VERIFY بدهد اما EDIT روی draft-v2 کار کند، lineage شکسته است. ظاهر خوبِ متن این خطا را جبران نمی‌کند.
8) Source bundle و claim set همراه artifact حرکت می‌کنند
source_bundle_ref و claim_set_ref باید در handoff باقی بمانند. rewrite می‌تواند واژگان را تغییر دهد، اما نباید claim را از source جدا کند یا caveat منبع‌دار را بدون ثبت حذف کند. این دقیقاً failure مهم transfer این درس است.
9) Disagreement باید state باشد، نه کامنت گم‌شدنی
وقتی VERIFY اعتراض می‌کند، disagreement_state=DISPUTED_UNRESOLVED تا زمانی باقی می‌ماند که disposition روی همان artifact version ثبت شود. توافق چهار مدل دیگر اعتراض حل‌نشده را باطل نمی‌کند.
10) Fallback یک substitution بی‌هزینه نیست
اگر drafting model در دسترس نباشد، fallback می‌تواند ادامهٔ کار را ممکن کند؛ اما اگر دو caveat منبع‌دار را حذف کند، state درست REWORK_FALLBACK_DRIFT است. latency پایین یا prose بهتر اجازهٔ عبور از review gate را نمی‌دهد.
11) Human anchor چرا لازم است؟
human_anchor_id شخص/نقش پاسخ‌گوی release را مشخص می‌کند. model consensus نمی‌تواند آن را جایگزین کند. approval_state=APPROVED هم فقط برای artifact lineage جاری معتبر است؛ هر تغییر مادی بعد از approval نیازمند review مجدد است.
12) Evidence Contract اصلی
Artifact نهایی ۲۰ dimension دارد. ۱۶ dimension بحرانی‌اند و فقدان هرکدام می‌تواند release را متوقف کند. جدول زیر یک نمونهٔ traceable از stageهاست؛ برای تصمیم واقعی CSV/JSON را بخوانید.
| Role | Input → Output | Provider / Model | Source / Claims | Review | Disagreement | Human / Approval | Release |
|---|---|---|---|---|---|---|---|
| RESEARCH | brief-v1 → research-v1 | provider-A / model-A1 | SRC-17 / CLAIMS-0 | N/A | NONE | H-9 / PENDING | NOT_RELEASED |
| DRAFT | research-v1 → draft-v3 | provider-B / model-B2 | SRC-17 / CLAIMS-7 | N/A | NONE | H-9 / PENDING | NOT_RELEASED |
| VERIFY | draft-v3 → verify-v1 | provider-C / model-C4 | SRC-17 / CLAIMS-7 | PASS | RESOLVED | H-9 / PENDING | NOT_RELEASED |
| EDIT | draft-v3 → final-v4 | provider-D / model-D1 | SRC-17 / CLAIMS-7 | VERIFY_PASS_PRESERVED | RESOLVED | H-9 / PENDING | NOT_RELEASED |
| APPROVE | final-v4 → final-v4 | HUMAN / N/A | SRC-17 / CLAIMS-7 | APPROVED | RESOLVED | H-9 / APPROVED | RELEASED |
برای audit واقعی، همهٔ ۲۰ فیلد CSV/JSON را بررسی کنید؛ این جدول Markdown فقط نمای فشرده است.
13) Baseline صحیح
در baseline، هر stage model identity، artifact handoff، source bundle و review state دارد. VERIFY بدون objection باز تمام می‌شود، human anchor همان artifact نهایی را APPROVE می‌کند و سپس release_state=RELEASED می‌شود. release نتیجهٔ evidence است، نه default workflow.
14) میانبرهای غلط و تعمیر آن‌ها
سه میانبر رایج: حذف model identity در VERIFY، overwrite کردن objection توسط EDIT، و نگه‌داشتن approval قدیمی بعد از fallback. تعمیر هر سه یکسان نیست: اول field/state دقیق خراب را پیدا کنید، بعد فقط همان gate را از evidence جاری بازسازی کنید. هیچ‌کدام با «مدل‌ها موافق بودند» تعمیر نمی‌شود.
15) Lab و Transfer
Lab شامل ۸ fixture آفلاین و ۴۸ assertion قطعی است. در transfer، drafting model اصلی unavailable می‌شود و fallback دو caveat منبع‌دار را حذف می‌کند. باید از روی evidence جدید تصمیم را بازسازی کنید: claim provenance را حفظ کنید، disagreement/rework را صریح کنید و تا approval انسانی روی artifact فعلی release نکنید.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
COM-006-S1 retrieval
What does COM-006 own, and what remains outside its boundary?
COM-006-S2 application
Build Editorial Cell Orchestration Contract v1 for the baseline synthetic run.
COM-006-S3 diagnosis
VERIFY has an objection, but EDIT rewrites the text and drops the objection record. Which state must block release and what is the minimal repair?
COM-006-S4 transfer
The preferred drafting model is unavailable and a fallback drops two source-linked caveats. Recompute rework, disagreement and release readiness without changing the human anchor.
ملاک‌های ارزیابی (rubric)
Blocking dimensions: identity/contract, exact evidence binding, negative evidence, bounded release decision, and changed-context transfer. A fluent final artifact cannot compensate for a broken lineage, missing model identity, unresolved verifier objection, missing human approval or missing decisive evidence.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
Source bundle flows through research, draft, verify and edit; unresolved disagreement goes to rework and release requires human approval.
فایل‌های آزمایشگاه
python run_checks.py را اجرا کنید. همهٔ fixtureها مصنوعی و آفلاین‌اند. هدف، حفظ هویت stage/model، lineage artifact، اعتراض verifier، پیوند claim/source و approval انسانی است. oracle داخل مسیر learner قرار ندارد.