معماری چندکسبوکاری، تجاری و تجارت الکترونیک · فصل ۵ — Editorial Cell، SEO، QA، Approval و Onboarding · 247
Multi-model Editorial Cell
Design a bounded multi-model editorial cell in which research, drafting, verification, editing and approval have typed responsibilities, versioned handoffs, visible model/provider identity, disagreement states, deterministic acceptance checks and a human release anchor; no model output becomes publishable merely because another model agrees with it. میتواند «Multi-model Editorial Cell» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
Lesson summary
Design a bounded multi-model editorial cell in which research, drafting, verification, editing and approval have typed responsibilities, versioned handoffs, visible model/provider identity, disagreement states, deterministic acceptance checks and a human release anchor; no model output becomes publishable merely because another model agrees with it.
میتواند «Multi-model Editorial Cell» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
This lesson produces
میتواند «Multi-model Editorial Cell» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
Who it is for
Foundation
Use a field map, one worked scenario and explicit state vocabulary before independent construction.
Repair
Identify the failed evidence dimension, use the smallest mutated fixture and rerun only the affected gate.
Experienced
Compress definitions; require trade-off defense, counterexample analysis and changed-context transfer.
Prerequisites
1) The problem this lesson owns
Adding more models does not automatically make an editorial workflow trustworthy. A chain of RESEARCH, DRAFT, VERIFY and EDIT prompts can produce polished copy while hiding which source supported a claim, which model changed it, and whether a verifier objection was ever resolved.
2) Exact COM-006 boundary
This lesson owns Editorial Cell Orchestration Contract v1. It does not own provider ranking/routing (COM-007) or niche/intent research (COM-005). The question here is how to make a bounded multi-model editorial cell replayable, reviewable and human-releasable.
3) FACT: model identity is a runtime dependency
OpenAI's current model catalog exposes concrete model identifiers and different capability/selection profiles. Recording only “OpenAI” or “AI writer” is not enough for replay. Preserve model_provider and model_id with the stage artifact.
4) FACT: Gemini also exposes model variants/version forms
Gemini documentation distinguishes model variants and version-name patterns such as stable, preview, latest and experimental. A family label or moving alias is therefore not complete provenance; record the concrete model identity used by the stage.
5) Multiple models mean typed responsibilities, not votes
MAKNOW separates RESEARCH → DRAFT → VERIFY → EDIT → APPROVE. VERIFY is not merely another opinion: it emits a review result bound to an artifact version. If EDIT changes that artifact, an objection needs a recorded disposition rather than disappearing inside a rewrite.
6) What a stage contract does
Before execution, define allowed input, expected output, evidence that must survive the handoff, and failure states. stage_contract prevents EDIT from silently inventing source support or APPROVE from becoming an untracked rewriting stage.
7) Handoffs must be versioned
Every transition records input_artifact_id and output_artifact_id. If VERIFY reviews draft-v3 but EDIT starts from draft-v2, lineage is broken. Fluent final prose does not compensate for that break.
8) Source bundle and claim set travel with the artifact
Keep source_bundle_ref and claim_set_ref attached through transformations. Rewriting may change wording, but it must not silently detach a claim from evidence or delete a source-linked caveat without an explicit review state.
9) Disagreement is a state, not a disposable comment
When VERIFY objects, DISPUTED_UNRESOLVED remains active until a disposition is recorded against the current artifact version. Agreement among several other models does not cancel an unresolved objection.
10) Fallback is not a free substitution
A fallback drafting model may restore availability. But if it drops two source-linked caveats, the correct state is REWORK_FALLBACK_DRIFT. Better style, lower latency or lower cost cannot compensate for lost claim support.
11) Why the human anchor matters
human_anchor_id identifies the accountable release reviewer. Model consensus cannot replace it. An APPROVED state is also bound to the current artifact lineage; a material edit after approval requires renewed review.
12) Core Evidence Contract
The artifact has 20 dimensions, 16 of them critical. Missing critical evidence can stop release. The compact table below shows a traceable baseline; use the CSV/JSON artifact for the complete field set.
| 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 |
Use the CSV/JSON artifact for all 20 evidence fields; this Markdown view is intentionally compact.
13) Correct baseline
Each stage preserves model identity, artifact handoff, source bundle and review state. VERIFY closes without an unresolved objection, the human anchor approves the current final artifact, and only then does release_state=RELEASED become valid.
14) Tempting shortcuts and repairs
Common shortcuts are removing model identity from VERIFY, letting EDIT overwrite an objection, and reusing old approval after a fallback rewrite. Repair starts by identifying the exact broken field/state and rerunning the affected gate from current evidence. “The models agreed” is never the repair.
15) Lab and transfer
The lab contains eight offline fixtures and 48 deterministic assertions. In transfer, the preferred drafting model is unavailable and a fallback drops two source-linked caveats. Recompute from changed evidence: preserve claim provenance, surface disagreement/rework, and do not release until a human approves the current artifact.
Assessment
There is no answer key in this lesson pack; answer it yourself and mark honestly. "Needs review" sends the lesson to your review queue.
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.
Assessment 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.
References & freshness
Case studies
Lesson visuals
Source bundle flows through research, draft, verify and edit; unresolved disagreement goes to rework and release requires human approval.
Lab files
python run_checks.py را اجرا کنید. همهٔ fixtureها مصنوعی و آفلایناند. هدف، حفظ هویت stage/model، lineage artifact، اعتراض verifier، پیوند claim/source و approval انسانی است. oracle داخل مسیر learner قرار ندارد.