Virtual Cast Persona Model

1. مسئله: شخصیت قابل‌شناسایی، بستهٔ Permission نیست

یک Virtual Presenter می‌تواند همان نام، چهره، لحن و Voice را حفظ کند اما Runtime Model، Toolها، Memory، Canon reference یا Action Authority آن عوض شود. اگر این لایه‌ها در یک «Persona Prompt» ادغام شوند، یک تغییر ظاهری می‌تواند ناخواسته Permission عملیاتی را هم منتقل کند. خروجی این درس Virtual Cast Persona Contract & Identity Matrix v1 است تا Presentation Identity بدون تبدیل‌شدن به میان‌بُر Authority پایدار بماند.

2. مرز درس

PLN-025 مالک Persona Contract است. Account/Quota درس PLN-024 و Canon Promotion درس PLN-026 را جذب نمی‌کند و هیچ Agent واقعی را mutate نمی‌کند. همه Evidenceها Synthetic و Offline هستند. هدف این است که دقیقاً معلوم شود کدام Field فقط Presentation است و کدام Field باید جداگانه مجوز و Provenance داشته باشد.

3. FACT خارجی و MAKNOW DESIGN

Agents SDK فعلی، Agent را با Instructions، Tools، Handoffs، Guardrails و Output behavior صریح مدل می‌کند. Handoff کنترل را به Agent دیگر منتقل می‌کند و Context منتقل‌شده می‌تواند فیلتر شود. Model Spec عمومی نیز Authority دستور را از Untrusted Content جدا می‌کند. اما جداکردن Persona Presentation، Runtime Binding، Tools، Memory، Canon، Claims، Disclosure و Execution Authority در این قرارداد MAKNOW DESIGN است.

4. Cast Member باید Identity و Version پایدار داشته باشد

با persona_id و persona_version شروع کن. display_name، narrative_role، audience و voice_style Presentation continuity را توصیف می‌کنند. تغییر Voice Style می‌تواند Version جدید بخواهد، اما نباید Tool، Memory، Canon یا Authority را بی‌صدا عوض کند.

5. Instruction Profile را از ظاهر جدا Bind کن

instruction_profile_ref مجموعه Instructionهای governed را مشخص می‌کند. همان شخصیت می‌تواند در زمان‌های مختلف Runtime متفاوت داشته باشد و Instruction Profile باید مستقل از Style قابل Review باشد. اگر Persona Version عوض شود ولی Binding معتبر Instruction Profile نداشته باشیم، State باید HOLD بماند.

6. Runtime Agent یک لایهٔ مستقل است

runtime_agent_ref می‌گوید کدام Agent Configuration واقعاً اجرا می‌شود. استفاده از یک Model family مساوی Runtime identity یکسان نیست. Presenter Agent و Operations Agent می‌توانند مدل مشترک داشته باشند ولی Tool، Memory، Handoff و Claim Authority کاملاً متفاوت داشته باشند.

7. Tool Scope باید مخصوص همان Persona باشد

tool_scope مشخص می‌کند Runtime اجازهٔ فراخوانی چه Toolهایی را دارد. صرفاً چون دو Persona یک Model دارند، Scope را کپی نکن. Tool scope کپی‌شده بدون Authorization مخصوص Persona → RESTRICTED. شباهت Presentation هیچ Side Effect Permission ایجاد نمی‌کند.

8. Memory Scope باید Lifetime داشته باشد

memory_scope باید Session-local context را از Durable persona memory جدا کند. Fact مفید در یک Run می‌تواند SESSION_LOCAL بماند؛ Durable شدن آن نیازمند Transition governed جداگانه است. استفاده از Session Memory به‌عنوان هویت دائمی، continuity نیست؛ Scope Leakage است.

9. Canon Scope و Claim Class با Voice Style فرق دارند

canon_scope_ref به مجموعهٔ reviewed قابل استناد اشاره می‌کند و allowed_claim_classes / prohibited_claims می‌گویند Persona چه نوع ادعایی می‌تواند مطرح کند. Voice note یا Style guide بدون Provenance Canon نیست. نبود Provenance قطعی در Canon → UNKNOWN، نه «احتمالاً معتبر».

10. Handoff و Disclosure قرارداد مستقل دارند

handoff_scope مقصدهای مجاز Delegation و Boundary آن را مشخص می‌کند. disclosure_profile هم می‌گوید چه محدودیت یا Identity disclosure باید دیده شود. Handoff فقط Execution Topology را عوض می‌کند؛ Narrative Persona را authoritativeتر نمی‌کند.

11. Authority State از Evidence محاسبه می‌شود

authority_state نتیجهٔ Evidence Contract است، نه لحن Persona. ACTIVE فقط وقتی صادر می‌شود که Version/Instruction binding، Runtime binding، Tool/Memory/Canon/Claim/Handoff scopes و Provenance همگی بسته باشند. Evidence ناقص → UNKNOWN یا HOLD؛ Policy محدودکننده → RESTRICTED؛ Conflict حل‌نشده → INCONCLUSIVE؛ Persona بازنشسته → RETIRED.

12. Baseline — Host مشخص با Scopeهای جدا

Host پایه CAST-HOST-01@3.2 از Voice Style warm-explainer-v3 استفاده می‌کند، اما Runtime، Tools، Durable Memory، Canon، Claims، Handoffs، Disclosure و Provenance مستقل ثبت شده‌اند. چون تمام Critical Dimensionها بسته‌اند، State برابر ACTIVE است. جدول نشان می‌دهد Caseهای شبیه چرا همان State را به ارث نمی‌برند.

13. Shortcutهای خطرناک

1. tool_scope را از Operations Persona به‌خاطر Model مشترک کپی کنی → RESTRICTED. ۲) Voice-style note را بدون Provenance Canon کنی → UNKNOWN. ۳) Session Memory را Permanent Persona Memory فرض کنی → SESSION_LOCAL. ۴) Persona Version را عوض کنی ولی Instruction Profile binding نداشته باشی → HOLD. ۵) Conflict بین Claim authorityها را پنهان کنی → INCONCLUSIVE.

14. Transfer — Voice یکسان، Audience و Authority متفاوت

Cast Member جدید همان Voice Style را استفاده می‌کند، اما Audience آن Procurement است نه Learner عمومی. Tool scope آن فقط Procurement lookup خواندنی است، Memory آن Session-only می‌ماند و Canon scope به مجموعه Reviewed دیگری اشاره می‌کند. ردیف از Evidence جدید دوباره محاسبه می‌شود؛ Permissionهای Persona قبلی فقط به‌خاطر Voice آشنا کپی نمی‌شوند.

15. Lab، Assessment و Freshness

در lab/PLN-025-LAB1/learner/ دستور python run_checks.py را اجرا کن. هشت Fixture شامل Baseline، Copied Tool Scope، Voice Note as Canon، Session Memory Leak، Version/Instruction Gap، Authority Conflict، Retired Persona و Transfer New Cast است. Claimهای Agents SDK و Model Spec در 2026-09-16 دوباره بررسی شده‌اند. هر تغییر Canonical Package نیازمند Version جدید است.