Virtual Cast / Repair Agent Deep Implementation Awareness

دو فناوری جذاب، دو تصمیم مستقل

فرض کنید یک محصول رسانه‌ای-آموزشی دو ایده دارد: یک Virtual Cast واقع‌گرایانه که در ده‌ها درس تکرار شود، و یک Repair Agent که خرابی دارایی یا کد را پیدا کند و پیشنهاد اصلاح بدهد. هر دو ایده ممکن است در نمایش اولیه بسیار قانع‌کننده باشند؛ اما کیفیت نمایش اولیه نه نیاز واقعی محصول را ثابت می‌کند و نه مجوز استفاده در محیط تولید را می‌دهد.

برای Virtual Cast باید جداگانه روشن کنید چه مسئلهٔ تکرارشونده‌ای وجود دارد، چه محرک قابل‌اندازه‌گیری ورود به زنجیرهٔ فنی عمیق‌تر را توجیه می‌کند، مالک هویت و حقوق استفاده چه کسی است، زنجیرهٔ دارایی/ثبت حرکت/انیمیشن/رندر چگونه کار می‌کند، هدف کیفیت و کارایی چیست، مسئول تولید چه کسی است، هزینه چقدر است و آیا راه ساده‌تری هنوز نیاز را برآورده می‌کند. مستندات فعلی MetaHuman نشان می‌دهند Epic چارچوبی برای ساخت، انیمیت و استفاده از انسان‌های دیجیتال rigged و photoreal ارائه می‌کند و مسیرهای Creator، Capture، Animator و Crowds را پوشش می‌دهد. این یک واقعیت دربارهٔ قابلیت ابزار است، نه مجوز MAKNOW برای انتخاب Virtual Cast. [METAHUMAN]

برای Repair Agent یک دروازهٔ مستقل لازم است: خرابی باید قابل بازتولید باشد؛ tool scope و write scope باید محدود و صریح باشند؛ برنامهٔ اصلاح، تأیید انسانی، Guardrail، آزمون و ارزیابی، rollback، ردهٔ اثر جانبی و audit trace باید قابل بررسی باشند. مستندات فعلی OpenAI Agents SDK ابزارها، Guardrail های، tracing و human-in-the-loop را پوشش می‌دهند. HITL می‌تواند فراخوانی حساس ابزار را برای تصمیم انسانی متوقف و سپس اجرا را ادامه دهد؛ Guardrail ابزار نیز می‌تواند فراخوانی function tool را پیش یا پس از اجرا بررسی یا مسدود کند. این سازوکارها به‌تنهایی درستی اصلاح، امکان بازگشت یا ایمنی محیط تولید را ثابت نمی‌کنند. [AGENTSDK] [AGENTHITL] [AGENTGUARD]

محصول یادگیری این درس Virtual Cast/Repair Agent Deep-Implementation Gate v1 است؛ دو محور مستقل با وضعیت‌های محدود USE، PILOT، NOT_NOW، UNKNOWN، EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED و HOLD.

زمان فعال برنامه‌ریزی‌شده: ۴۵ دقیقه.

مرز درس: AWR-008 فقط آگاهی تصمیم‌محور برای پیاده‌سازی عمیق Virtual Cast و Repair Agent را در اختیار دارد. نتیجهٔ AWR-007 دربارهٔ Multi-region/Autonomous Ad Buying و نتیجهٔ D3D-001 دربارهٔ مدل‌سازی سه‌بعدی تولیدی وارد این درس نمی‌شوند. این درس هیچ Virtual Castی منتشر نمی‌کند و به هیچ Repair Agentی مجوز نوشتن در محیط تولید نمی‌دهد.

پیش‌نیاز سخت — AWR-005

پیش از شروع باید بتوانید مرز موردنیاز از AWR-005 را توضیح دهید. اگر شواهد شما دربارهٔ این پیش‌نیاز شکننده است، از پل محدود همان پیش‌نیاز استفاده کنید؛ تکمیل آن درس را جعل نکنید.

پیش‌نیاز نرم — AWR-007

از AWR-007 فقط مرزی را همراه بیاورید که برای این درس لازم است. نتیجهٔ آن درس را داخل AWR-008 دوباره‌سازی نکنید.

پیش از انتخاب ابزار، دو محور را جدا کنید

چهار پرسش تشخیصی:

1. اگر MetaHuman یا چارچوب دیگری بتواند یک شخصیت photoreal بسازد، آیا همین توانایی ثابت می‌کند محصول شما به Virtual Cast نیاز دارد؟
2. اگر یک Repair Agent یک خطای مصنوعی را اصلاح کند، آیا بدون آزمون، rollback و write scope محدود می‌توان آن را برای repository یا محیط تولید آماده دانست؟
3. اگر مالک حقوق Virtual Cast نامشخص باشد ولی کیفیت نمایش عالی باشد، آیا USE یا PILOT مجاز است؟
4. اگر شواهد Virtual Cast کامل باشد ولی هدف Repair Agent به billing code و production data برسد، آیا نتیجهٔ هر دو محور باید یکسان باشد؟

۴ از ۴ → مسیر سریع. ۲ تا ۳ → مسیر اصلاح. ۰ تا ۱ → مسیر پایه.

مسیر سریع فقط توضیح‌های پایه را فشرده می‌کند و سطح شواهد را پایین نمی‌آورد. مسیر اصلاح، نخستین بُعد شواهدی ناموفق را جدا می‌کند. مسیر پایه، نقشهٔ کامل فیلدها و یک نمونهٔ هدایت‌شده را در اختیار می‌گذارد. هیچ مسیری اجازه ندارد دو محور را به یک نتیجهٔ مشترک تبدیل کند.

خودسنجی مسیر: توانایی ابزار را از محرک پذیرش، کیفیت را از حقوق و مالکیت، Guardrail را از درستی و rollback، و نتیجهٔ انتقال را از شواهد حالت قبلی جدا کنید.

مدل ذهنی: مسئله → محرک → اختیار → شواهد → هزینه/کنترل → تصمیم

برای هر محور این ترتیب را حفظ کنید:

تناسب مسئله → محرک قابل‌اندازه‌گیری → مالک/اختیار → شواهد فنی → هزینه یا کنترل اثر جانبی → راه ساده‌تر → وضعیت محدود → شرط صریح توقف/تغییر مسیر + محرک‌های لازم برای بازبینی/مهاجرت/ارجاع

دو جریان مستقل:

Virtual Cast → نقش و نیاز به تکرار → هویت و حقوق → دارایی/capture/animation/render → کیفیت و بودجه → مسئول تولید → USE / PILOT / NOT_NOW / HOLD

Repair Agent → خطای قابل بازتولید → tool/write scope → approval & Guardrail → tests/eval → rollback & audit trace → USE / PILOT / NOT_NOW / REVIEW_REQUIRED

سه نوع اختیار را با هم مخلوط نکنید:

دارایی جدولی، دو محور را ردیف‌به‌ردیف قابل ممیزی می‌کند. دارایی جریان نیز ترتیب دروازه‌هایی را نشان می‌دهد که باید پیش از وضعیت مثبت طی شوند. اگر رندر بصری در دسترس نباشد، جدول متنی کامل و جریان متنی مرتب همان معنای آموزشی را حفظ می‌کنند.

پایه‌های مشترک برای آگاهی از پیاده‌سازی عمیق

۱. قابلیت ابزار با نیاز به پذیرش یکی نیست

MetaHuman چارچوبی برای ایجاد، انیمیت و استفاده از انسان‌های دیجیتال rigged و photoreal است و مستندات آن مسیرهای Creator، Capture، Animator و Crowds را نشان می‌دهد. [METAHUMAN] این واقعیت نمی‌گوید محصول شما به گروه ثابت شخصیت‌ها، چندین کاراکتر، performance capture یا زنجیرهٔ تولید اختصاصی نیاز دارد.

Agents SDK نیز Agent، ابزار، Guardrail، HITL و tracing دارد. [AGENTSDK] این قابلیت‌ها امکان کنترل فنی را نشان می‌دهند؛ اما به‌تنهایی توجیه یا ایمنی خودکارسازی اصلاح را ثابت نمی‌کنند.

۲. Virtual Cast از مالکیت شروع می‌شود، نه از کیفیت رندر

پیش از انتخاب مدل، rig یا capture، نقش‌ها، تعداد شخصیت‌ها، مالک هویت/حقوق و مسئول تولید را روشن کنید. اگر مالکیت برای شخصیت پیشنهادی حل نشده باشد، کیفیت بالا نمی‌تواند OWNER_MISSING را به USE تبدیل کند.

۳. هدف کیفیت بدون هدف هزینه و کارایی ناقص است

ممکن است شخصیت از نظر بصری پذیرفتنی باشد اما هزینهٔ رندر یا انیمیشن از بودجه عبور کند. این یک شاهد منفی واقعی است؛ قبولی کیفیت فقط یکی از دروازه‌هاست.

۴. Repair Agent به خطای قابل بازتولید نیاز دارد

عبارت «گاهی فایل‌ها خراب می‌شوند» کافی نیست. امضای خطا و fixture باید نشان دهند کدام ورودی مسئله را بازتولید می‌کند. بدون بازتولیدپذیری، موفقیت اصلاح را هم نمی‌توان معتبر سنجید.

۵. tool scope و write scope یک چیز نیستند

Repair Agent ممکن است اجازهٔ خواندن، جست‌وجو، پیشنهاد patch یا اجرای آزمون داشته باشد، در حالی که مجوز نوشتن جداگانه محدود شده است. PROPOSE_ONLY می‌تواند گزینه‌ای کم‌ریسک باشد؛ SANDBOX_PATCH_ONLY از نوشتن در repository یا محیط تولید محدودتر است.

۶. تأیید و Guardrail کنترل‌اند، نه اثبات درستی

HITL در Agents SDK می‌تواند فراخوانی حساس را تا تصمیم انسان متوقف کند. [AGENTHITL] Guardrail ابزار نیز می‌تواند function-tool invocation را پیش یا پس از اجرا بررسی یا مسدود کند. [AGENTGUARD] اما Guardrail اثر جانبی رخ‌داده را خودکار برنمی‌گرداند و approval به‌تنهایی درستی patch را ثابت نمی‌کند. آزمون/ارزیابی و rollback باید مستقل باقی بمانند.

۷. وضعیت غیرموفقِ نوع‌دار یک نتیجهٔ معتبر است

NOT_NOW می‌تواند یعنی راه ساده‌تر هنوز نیاز را با هزینه یا ریسک کمتر پوشش می‌دهد یا محرک کافی نیست. EVIDENCE_INCOMPLETE یعنی دادهٔ تعیین‌کننده ناقص است. OWNER_MISSING یعنی اختیار یا مالکیت حل نشده است. REVIEW_REQUIRED یعنی دامنه یا اثر جانبی به بازبینی بالاتر نیاز دارد. این وضعیت‌ها شکست آموزشی نیستند؛ جلوی اطمینان کاذب را می‌گیرند.

ساخت Virtual Cast/Repair Agent Deep-Implementation Gate v1

گام ۱ — دو محور تصمیم بسازید

دو ردیف مستقل VIRTUAL_CAST و REPAIR_AGENT داشته باشید. نتیجهٔ نهایی مشترک نسازید. ممکن است یک محور PILOT و دیگری NOT_NOW باشد.

گام ۲ — مسئله و محرک قابل‌اندازه‌گیری را بنویسید

برای Virtual Cast، محرک می‌تواند تکرار نقش‌ها، نیاز به ثبات هویت، حجم تولید یا نیاز واقعی قابل‌اندازه‌گیری باشد. «چون photoreal جذاب است» محرک نیست.

برای Repair Agent، محرک باید الگوی خطای تکرارشونده و هزینه یا زمان اصلاح انسانی را نشان دهد. «Agent می‌تواند کد بنویسد» محرک نیست.

گام ۳ — پیش از وضعیت مثبت، اختیار و مالکیت را حل کنید

Virtual Cast: identity_rights_owner و production_owner. Repair Agent: production_owner، مسئول approval و مسئول محدودهٔ مجاز.

اختیار نامشخص یعنی وضعیت مثبت مجاز نیست و باید یک وضعیت غیرموفقِ نوع‌دار حفظ شود.

گام ۴ — زنجیرهٔ فنی یا سطح کنترل را مشخص کنید

Virtual Cast: زنجیرهٔ دارایی، نیاز capture، نیاز animation، هدف render، بودجهٔ زمانی/فریم و هدف کیفیت.

Repair Agent: امضای خطا، tool scope، write scope، برنامهٔ patch و ردهٔ اثر جانبی.

گام ۵ — شواهد قابل آزمون اضافه کنید

Virtual Cast: شاهد کیفیت به‌علاوهٔ هزینهٔ render/animation در برابر بودجهٔ اعلام‌شده. Repair Agent: fixture آزمون قطعی، نتیجهٔ ارزیابی، وضعیت Guardrail، وضعیت approval، rollback و audit trace.

گام ۶ — راه ساده‌تر را واقعاً مقایسه کنید

برای Virtual Cast می‌توان recorded human video، stylized avatar یا جریان محدود presenter را مقایسه کرد. برای Repair Agent می‌توان اصلاح انسانی، اسکریپت قطعی، proposal-only agent یا خودکارسازی فقط در sandbox را سنجید.

اگر راه ساده‌تر همان نیاز را با هزینه یا ریسک کمتر پوشش می‌دهد، NOT_NOW می‌تواند نتیجهٔ درست باشد.

گام ۷ — تصمیم را از شواهد قوی‌تر نکنید

USE یا PILOT فقط زمانی مجاز است که ابعاد تعیین‌کنندهٔ همان محور صریح باشند. مالک، آزمون یا مسیر بازگشتِ گمشده را با زبان مطمئن جایگزین نکنید.

گام ۸ — شرط توقف/تغییر مسیر و محرک‌های حاکمیتی را صریح کنید

برای هر محور بنویسید چه وضعیتی باعث توقف یا تغییر مسیر می‌شود. سپس فقط محرک‌های حاکمیتی واقعاً مرتبط را نام ببرید: بازبینی، مهاجرت، ارجاع به سطح بالاتر، یا ترکیبی از آن‌ها. لازم نیست هر سه دسته را مکانیکی پر کنید. افزایش تعداد شخصیت‌ها، تغییر حقوق، تغییر بودجهٔ رندر، بالا رفتن ردهٔ اثر جانبی، گسترش write scope، امضای خطای جدید یا تغییر هدف نمونه‌هایی از شرایطی هستند که می‌توانند تصمیم را دوباره باز کنند.

گام ۹ — انتقال را از صفر دوباره محاسبه کنید

در محصول دوم ممکن است Virtual Cast با یک presenter دارای حقوق مستند و زنجیرهٔ پایدار بتواند پیش برود، در حالی که Repair Agent چون billing code و production data را لمس می‌کند در REVIEW_REQUIRED یا NOT_NOW بماند. مهارت اصلی همین بازسازی مستقل تصمیم‌ها از شواهد جدید است.

مثال کامل: یک محصول، دو نتیجهٔ متفاوت

این مثال از Lab جداست و پاسخ آن را از پیش پر نمی‌کند.

محصول فرضی SYNTH-MEDIA-B سه presenter تکرارشونده دارد. حقوق دو نفر ثبت شده اما برای نفر سوم مالک حقوق مشخص نیست. زنجیرهٔ دارایی، هدف رندر و نمونهٔ کیفیت روشن‌اند. نتیجهٔ این محور نمی‌تواند مثبت باشد؛ تا حل مالکیت، OWNER_MISSING وضعیت دقیق‌تری است.

در همان محصول، Repair Agent فقط روی دارایی‌های مصنوعی درس کار می‌کند. امضای خطا روشن است، patch فقط در sandbox نوشته می‌شود، approval پیش از نوشتن وجود دارد، مجموعه‌آزمون قطعی قبول می‌شود، rollback از snapshot ممکن است و audit trace نگه‌داری می‌شود. این شواهد می‌توانند یک PILOT محدود را توجیه کنند، بدون آن‌که مجوز نوشتن در محیط تولید یا اصلاح billing code صادر شود.

نکته این نیست که Repair Agent همیشه شایستهٔ PILOT است؛ نکته این است که شواهد هر محور، نتیجهٔ همان محور را می‌سازند. اگر هدف اصلاح بعداً به production data منتقل شود، نتیجهٔ حالت مبنا باید کنار گذاشته و تصمیم دوباره ساخته شود.

میان‌بُرهایی که اطمینان کاذب می‌سازند

1. «نمایش photoreal خوب است، پس Virtual Cast لازم است.» اصلاح: مسئله، محرک و راه ساده‌تر را پیش از زنجیرهٔ فنی بررسی کنید.
2. «چارچوب، حقوق هویت را حل می‌کند.» اصلاح: مالکیت حقوق را محلی، صریح و قابل ردیابی نگه دارید.
3. «کیفیت قبول شد، پس هزینه مهم نیست.» اصلاح: برآورد render/animation را با بودجه مقایسه کنید.
4. «Repair Agent یک خطا را اصلاح کرد، پس خودکارسازی آماده است.» اصلاح: بازتولید خطا، آزمون قطعی و انتقال را جدا بسنجید.
5. «approval انسانی داریم، پس اثر جانبی امن است.» اصلاح: approval را از rollback و درستی جدا کنید. [AGENTHITL]
6. «Guardrail داریم، پس همهٔ فراخوانی‌های ابزار امن‌اند.» اصلاح: دامنه و زمان اعمال Guardrail را دقیق ثبت کنید؛ Guardrail کنترل است، نه اثبات. [AGENTGUARD]
7. «PROPOSE_ONLY یعنی Repair Agent بی‌فایده است.» اصلاح: آن را به‌عنوان راه کم‌ریسک‌تر بسنجید؛ شاید مجوز نوشتن عمیق اصلاً لازم نباشد.
8. «دو محور باید یک سطح بلوغ داشته باشند.» اصلاح: تصمیم‌ها مستقل‌اند.
9. «مستندات فروشنده مجوز پذیرش فناوری هستند.» اصلاح: FACT را از MAKNOW DESIGN جدا کنید.
10. «حالت مبنا قبول شد، پس در انتقال همان پاسخ را کپی می‌کنیم.» اصلاح: هر محدودیت تغییرکرده را دوباره محاسبه کنید.

پل برای یادگیرندهٔ باتجربه: مسئله را دو ماشین حالت ببینید

اگر پیش‌تر virtual production یا agentic tooling ساخته‌اید، ارزش این درس در نام ابزارها نیست؛ در نسخه‌پذیر کردن اختیار و شواهد است.

برای Virtual Cast، ماشین حالت را حول rights → production pipeline → quality/performance → budget → owner بسازید. برای Repair Agent، آن را حول failure → tool/write authority → approval/guardrails → tests/eval → rollback/audit بسازید.

دو جداسازی حرفه‌ای مهم است:

• «می‌تواند انجام دهد» با «اجازه دارد انجام دهد» یکی نیست.
• «یک‌بار موفق شد» با «قابل تکرار و قابل بازگشت است» یکی نیست.

در بازبینی طراحی، مشخص کنید کدام داده دروازهٔ سخت است، کدام شاهد نقش مشورتی دارد و کدام مورد باید به سطح بالاتر ارجاع شود. از امتیاز وزنی ساختگی که تفاوت حقوق، بودجه و اثر جانبی را در یک عدد پنهان می‌کند دوری کنید.

موازنه‌ها بدون برندهٔ دائمی

Virtual Cast در برابر recorded human video: گروه مجازی می‌تواند ثبات و استفادهٔ مجدد بدهد، اما به زنجیرهٔ دارایی/capture/animation/render، حقوق و مسئول تولید نیاز دارد. ویدئوی انسانی ممکن است ساده‌تر و ارزان‌تر باشد، هرچند انعطاف کمتری برای استفادهٔ مجدد داشته باشد.

گروه photoreal در برابر stylized avatar: واقع‌گرایی می‌تواند هدف بصری خاصی را برآورده کند اما هزینهٔ render/capture و حساسیت هویتی را بالا ببرد. روش stylized ممکن است مسئلهٔ محصول را با پیچیدگی کمتر حل کند.

اصلاح انسانی در برابر proposal-only agent: انسان کندتر است اما اختیار روشن دارد. عامل فقط-پیشنهاد می‌تواند بررسی اولیه را سریع کند بدون آن‌که فایلی بنویسد و شاید همان مرحلهٔ مناسب فعلی باشد.

اصلاح در sandbox در برابر repository/production: sandbox دامنهٔ آسیب را محدود و آزمون/rollback را ساده‌تر می‌کند. نوشتن در billing code یا production data به سطح بسیار بالاتری از بازبینی، مجوز، مشاهده‌پذیری و بازیابی نیاز دارد؛ این درس چنین اختیاری نمی‌دهد.

HITL در برابر اجرای کاملاً خودمختار: approval می‌تواند دروازه‌ای مهم باشد، اما زمان و بار عملیاتی اضافه می‌کند. حذف آن فقط زمانی قابل بررسی است که شواهد مستقل دربارهٔ دامنه، آزمون‌ها، اثر جانبی و rollback قوی‌تر شده باشند. [AGENTHITL]

تمرین هدایت‌شده و مستقل

بخش A — حالت مبنا را بدون نتیجهٔ ازپیش‌پرشده بسازید

lab://AWR-008/AWR-008-LAB1 را باز کنید. baseline_fixture.json شواهد مصنوعی دو محور را دارد اما مقدار decision در آن حل نشده است. gate_evidence.template.json را پر کنید، fixture_ref را به شناسهٔ fixture واقعی متصل کنید و برای هر محور وضعیت، استدلال، شرط توقف/تغییر مسیر و محرک‌های حاکمیتی مرتبط را جدا بنویسید.

بررسی‌گر فقط سازگاری با قواعد آشکار و اتصال دقیق به fixture ارسال‌شده را می‌سنجد. CONSISTENT به معنی تأیید پذیرش فناوری، پاک بودن حقوقی یا ایمنی محیط تولید نیست.

بخش B — تغییرهای آزمایشی را جدا تشخیص دهید

1. تعداد شخصیت‌ها را بدون مالک جدید حقوق/تولید افزایش دهید؛
2. کیفیت بصری را حفظ کنید اما برآورد رندر را از بودجه بالاتر ببرید؛
3. Repair Agent را به PROPOSE_ONLY محدود کنید؛
4. نوشتن در repository را اضافه کنید اما آزمون قطعی یا rollback را حذف کنید؛
5. هدف اصلاح را به billing code و production data منتقل کنید.

برای هر تغییر فقط فرض شکسته‌شده، پیامد و کمینهٔ اصلاح یا تغییر تصمیم را بنویسید.

بخش C — انتقال را دوباره محاسبه کنید

transfer_fixture.json یک presenter تکرارشونده با حقوق مستند و زنجیرهٔ پایدار دارد، اما کار Repair Agent به billing code و production data می‌رسد. نتیجه‌های حالت مبنا را کپی نکنید؛ دو محور ممکن است به وضعیت‌های متفاوت برسند.

راستی‌آزمایی: بازبین باید هر محور را بدون حدس بازسازی کند

برای Virtual Cast، بازبین باید این زنجیره را ببیند:

1. مسئله و محرک؛
2. نقش‌ها و تعداد شخصیت‌ها؛
3. مالک هویت/حقوق؛
4. زنجیرهٔ asset/capture/animation/render؛
5. شاهد کیفیت؛
6. مسئول تولید؛
7. هزینه و بودجه؛
8. راه ساده‌تر؛
9. وضعیت محدود، شرط صریح توقف/تغییر مسیر و محرک‌های مرتبط برای بازبینی/مهاجرت/ارجاع.

برای Repair Agent:

1. امضای خطای قابل بازتولید؛
2. هدف اصلاح؛
3. tool scope و write scope؛
4. برنامهٔ patch و ردهٔ اثر جانبی؛
5. نیاز به approval و مسئول آن؛
6. وضعیت Guardrail؛
7. fixture آزمون قطعی و نتیجهٔ ارزیابی؛
8. rollback؛
9. audit trace؛
10. راه ساده‌تر؛
11. وضعیت محدود، شرط صریح توقف/تغییر مسیر و محرک‌های مرتبط برای بازبینی/مهاجرت/ارجاع.

اگر دادهٔ تعیین‌کننده‌ای خالی است، یک وضعیت غیرموفقِ نوع‌دار را حفظ کنید. بررسی‌گر اجازه ندارد شاهد گمشده را حدس بزند یا پاسخ مطلوب تولید کند.

ارزیابی و انتقال

ارزیابی نهایی چهار بخش مسدودکننده دارد:

1. مرز متعلق به AWR-008 را توضیح دهید، یک non-goal مجاور نام ببرید و FACT بیرونی را از MAKNOW DESIGN جدا کنید؛
2. برای fixture حالت مبنا، Virtual Cast/Repair Agent Deep-Implementation Gate v1 را با دو تصمیم مستقل بسازید؛
3. تغییر «شخصیت بیشتر بدون مالک جدید حقوق/تولید» را تحلیل و دادهٔ نامعتبر، پیامد و کمینهٔ اصلاح را مشخص کنید؛
4. در محصول دوم، Virtual Cast با presenter دارای حقوق و زنجیرهٔ پایدار را مستقل از Repair Agentی که billing code و production data را لمس می‌کند دوباره ارزیابی کنید.

Rubric پنج بُعد بحرانی دارد: identity_and_contract، exact_evidence_binding، negative_evidence، bounded_decision و transfer.

AI می‌تواند شواهد مصنوعی را مرتب کند، دادهٔ گمشده را نشان دهد یا مقایسهٔ قطعی انجام دهد. اجازه ندارد مالک حقوق، محرک پذیرش، موفقیت اصلاح، approval یا اختیار تولید را اختراع کند.

منابع، تازگی و مرز ادعا

[AWR-008-K1 / FACT] مستندات MetaHuman چارچوبی برای ساخت، انیمیت و استفاده از انسان‌های دیجیتال rigged و photoreal توصیف می‌کنند و مسیرهای Creator، Capture، Animator و Crowds را نشان می‌دهند. [METAHUMAN] این واقعیت نیاز محصول به Virtual Cast یا کفایت شواهد حقوق و تولید را ثابت نمی‌کند.

[AWR-008-K2 / FACT] OpenAI Agents SDK ابزارها، Guardrail های، tracing و human-in-the-loop را ارائه می‌کند. [AGENTSDK] HITL می‌تواند فراخوانی حساس ابزار را متوقف و پس از تصمیم approve/reject اجرا را ادامه دهد. [AGENTHITL] این قابلیت مجوز نوشتن در repository یا محیط تولید نیست.

[AWR-008-K3 / FACT] Guardrail ابزار برای function tool می‌تواند فراخوانی را پیش یا پس از اجرا بررسی یا مسدود کند. [AGENTGUARD] این کنترل، rollback خودکار یا درستی patch را ثابت نمی‌کند.

[AWR-008-K4 / DESIGN] دروازهٔ دو محوره، واژگان وضعیت، سطح شواهد پذیرش و قواعد Lab در این درس از اختیار طراحی MAKNOW می‌آیند؛ مستندات فروشنده آن‌ها را تعیین نمی‌کنند.

این چهار منبع رسمی در 2026-09-07 بازبینی شده‌اند و همچنان از مرزهای قابلیت بالا پشتیبانی می‌کنند. موعد بازبینی بعدی 2026-12-02 است؛ اگر معنای فنی زنجیرهٔ انسان دیجیتال، رفتار ابزار/approval/Guardrail عامل‌ها یا دسترس‌پذیری منابع به‌طور معنادار تغییر کرد، بازبینی باید زودتر انجام شود.

برچسب‌های منبع در این درس به همان مراجع رسمی اشاره می‌کنند.