Human Anchor + AI Variants

1) مشکل اصلی: خروجی روان می‌تواند از پیام تأییدشده دور شده باشد

وقتی هر خروجی هوش مصنوعی به ورودی نسل بعد تبدیل شود، تیم خیلی زود منبع انسانیِ مورد تأیید را گم می‌کند. یک Variant ممکن است کاملاً طبیعی و حرفه‌ای باشد ولی قید مهمی را حذف کند، ادعای محصول را تغییر دهد یا فقط به این دلیل پذیرفته شود که شبیه آخرین خروجی AI است. در این درس، معیار ما «روان بودن» نیست؛ معیار این است که بتوانیم دقیقاً نشان دهیم هر Variant از کدام Anchor انسانی، با کدام نسخه و با چه مجوز تغییری مشتق شده است.

2) مرز COM-011: Anchor و Variant، نه QA Rubric و نه Playbook کانال

مالک این درس Human Anchor and AI Variant Lineage Contract v1 است. COM-010 درباره‌ی Rubric کیفیت محتواست و COM-012 درباره‌ی Playbook فرمت هر کانال. اینجا سؤال محدودتر است: «این Variant دقیقاً از کدام منبع انسانی مشتق شده، چه چیزهایی اجازه داشته تغییر کند، چه claimهایی محافظت شده‌اند و چه کسی اجازه‌ی Promotion دارد؟»

3) مدل ذهنی: Human Anchor → Generation Activity → AI Variant → Diff/QA → Human Review → Promotion

Anchor باید یک artifact انسانیِ نوشته‌شده یا انسانیِ تأییدشده باشد و anchor_id و anchor_version داشته باشد. Generation Activity فقط رخداد تولید را ثبت می‌کند. Variant مشتق است، نه منبع حقیقت جدید. سپس semantic/claim/style diff، QA و Human Review انجام می‌شود. خروجی می‌تواند VARIANT_PROMOTED، REWORK، RE_REVIEW، REJECT یا یک حالت HOLD/BLOCKED باشد.

4) FACT: W3C PROV برای lineage مناسب است، ولی fidelity یا approval را ثابت نمی‌کند

PROV-DM درباره‌ی Entity، Activity، Agent و derivation صحبت می‌کند. بنابراین می‌توان Anchor را یک Entity، فرایند generation را یک Activity و Variant را Entity مشتق‌شده مدل کرد. اما داشتن provenance فقط می‌گوید چه چیزی از چه چیزی و چگونه آمده است؛ ثابت نمی‌کند معنی Variant وفادار مانده یا یک انسان آن را تأیید کرده است. این مرز مهم است: lineage لازم است، اما کافی نیست.

5) FACT: NIST AI 600-1 ریسک Generative AI را در چرخه‌ی Govern/Map/Measure/Manage می‌بیند

پروفایل Generative AI در NIST AI RMF برای استفاده‌ی داوطلبانه و بین‌بخشی منتشر شده و مدیریت ریسک را در طول چرخه‌ی AI می‌بیند. از این Fact نمی‌توان نتیجه گرفت NIST گفته حتماً anchor_id یا stateهای MAKNOW داشته باشید. استفاده‌ی ما یک inference طراحی است: چون ریسک‌های GAI باید قابل govern، measure و manage باشند، lineage و human review باید شواهد قابل بازسازی داشته باشند.

6) Anchor Contract: ۲۲ فیلد برای جلوگیری از drift پنهان

Artifact اصلی این درس ۲۲ فیلد دارد. ۲۰ فیلد آن بحرانی‌اند و style_diff و supersedes_anchor بیشتر برای توضیح و کنترل نسخه کمک می‌کنند. جدول زیر سه وضعیت نمونه را نشان می‌دهد؛ جدول کامل باید برای هر Variant مستقل پر شود.

7) Parent باید به Anchor برگردد؛ زنجیره‌ی AI→AI نباید Anchor را محو کند

اگر Variant B فقط parent_artifact_id=Variant A داشته باشد و هیچ binding قابل اتکا به Anchor انسانی نداشته باشد، lineage برای تصمیم این درس ناقص است. اینجا state درست BLOCKED_LINEAGE است. استفاده‌ی فنی از یک Variant به‌عنوان ورودی ممکن است مجاز باشد، اما governance باید همچنان governing Anchor و نسخه‌ی آن را صریح نگه دارد.

8) Transformation Intent و Allowed Changes را قبل از Generation اعلام کنید

تغییر «لحن رسمی به محاوره‌ای» با تغییر «قیمت، مزیت، شرط یا ادعای محصول» یکی نیست. transformation_intent هدف را می‌گوید و allowed_change_dimensions دامنه‌ی تغییر مجاز را مشخص می‌کند. اگر تغییر مشاهده‌شده بیرون این دامنه باشد، similarity بالا هم نجات‌دهنده نیست؛ state باید REWORK_SCOPE_VIOLATION شود.

9) Protected Claims خط قرمز semantic هستند

protected_claim_ids claimهایی را مشخص می‌کند که Variant حق ندارد بدون review جدید به‌صورت مادی تغییر دهد. اگر claim_diff نشان دهد یکی از این claimها تغییر کرده، approval قبلی به‌طور خودکار منتقل نمی‌شود. state مناسب RE_REVIEW_PROTECTED_CLAIM است، حتی اگر style و semantic similarity کلی خوب به نظر برسد.

10) Diff عددِ جادویی برای approval نیست

semantic_diff، claim_diff و style_diff برای قابل‌دیدن کردن تفاوت‌اند. هیچ threshold عمومی وجود ندارد که بگوید «زیر این عدد، Variant حتماً امن است». Diff شواهد review است. تصمیم انسانی باید بفهمد چه چیزی عوض شده، نه اینکه فقط یک score را نگاه کند.

11) QA و Human Review دو gate جدا هستند

QA می‌تواند structure، presence، source references و ruleهای deterministic را بررسی کند؛ اما qa_run_ref=PASS به معنی approval انسانی نیست. اگر human_review_state هنوز PENDING باشد، state درست BLOCKED_HUMAN_REVIEW است. AI می‌تواند evidence را مرتب کند، ولی نمی‌تواند برای خودش authority انتشار بسازد.

12) Anchor Version تغییر کرد؟ Approval قدیمی را freeze کنید تا revalidation انجام شود

وقتی offer یا claim تأییدشده تغییر می‌کند و anchor_version=2 ساخته می‌شود، Variantهای v1 نباید بی‌سر و صدا APPROVED بمانند. اگر Variant هنوز به v1 bind شده، REVALIDATE_ANCHOR_VERSION می‌گیرد. بعضی Variantها ممکن است پس از compare دوباره معتبر بمانند؛ بعضی باید regenerate یا re-review شوند. rollback_ref هم باید نسخه‌ی قبلی و evidence آن را قابل بازیابی نگه دارد.

13) Failure Modeها و state درست

• Anchor یا evidence بحرانی گمشده → HOLD_MISSING_EVIDENCE
• Parent chain بدون Anchor انسانی → BLOCKED_LINEAGE
• Protected claim تغییر کرده → RE_REVIEW_PROTECTED_CLAIM
• تغییر بیرون allowed scope → REWORK_SCOPE_VIOLATION
• QA رد شده → REJECT_VARIANT
• Human Review انجام نشده → BLOCKED_HUMAN_REVIEW
• Anchor جدید شده و Variant قدیمی revalidate نشده → REVALIDATE_ANCHOR_VERSION
• همه‌ی gateها معتبر → VARIANT_PROMOTED

14) Lab و Transfer: Anchor v2 را بدون پاک کردن تاریخچه مدیریت کنید

در Lab، هشت Fixture را با evaluator deterministic اجرا می‌کنید. هدف این نیست که مدل «بهترین متن» را انتخاب کند؛ هدف این است که از evidence معلوم شود چرا یک Variant promote، hold، reject یا re-review می‌شود. در Transfer، Anchor v2 ایجاد می‌شود و باید فقط از روی lineage و evidence تصمیم بگیرید کدام Variantهای v1 هنوز قابل استفاده‌اند. این درس live publishing، rights clearance یا correctness واقعی مدل را ثابت نمی‌کند.