Virtual Cast Persona Model

1. Problem: a recognizable character is not a permission bundle

A virtual presenter can keep the same name, face, tone, and voice while its runtime model, tools, memory, canon references, or action authority change. If those layers are collapsed into one "persona prompt," a cosmetic edit can silently inherit operational permissions. This lesson produces Virtual Cast Persona Contract & Identity Matrix v1 so presentation identity remains recognizable without becoming a shortcut to authority.

2. Lesson boundary

PLN-025 owns the persona contract. It does not own PLN-024 account/quota controls or PLN-026 canon promotion rules, and it does not mutate a live agent. The evidence is synthetic and offline. The goal is to prove which persona fields are presentation-only and which fields must be separately authorized.

3. External FACT versus MAKNOW DESIGN

The current OpenAI Agents SDK models an agent with explicit instructions, tools, handoffs, guardrails, and output behavior. Handoffs transfer control to another agent and can change forwarded context. The public Model Spec separates instruction authority from untrusted content. MAKNOW DESIGN uses these boundaries to keep persona presentation, runtime binding, tools, memory, canon, claims, disclosure, and execution authority as separate fields.

4. Give the cast member a stable identity and version

Start with persona_id and persona_version. display_name, narrative_role, audience, and voice_style describe presentation continuity. A voice-style change may justify a new persona version, but it must not silently alter tool, memory, canon, or execution authority.

5. Bind instructions separately from the display persona

instruction_profile_ref identifies the governed instruction set. The same character can be rendered with multiple runtime configurations over time, and the same instruction profile can be reviewed independently from visual or voice styling. A persona-version change with no instruction-profile binding is HOLD.

6. Runtime agent identity is a different layer

runtime_agent_ref answers which executable agent configuration actually runs. Same model family does not mean same runtime identity. A presenter agent and an operations agent can share a model while having completely different tools, memory, handoffs, and allowed claims.

7. Tool scope must be persona-specific

tool_scope lists what the runtime is permitted to call. Never copy it from another persona merely because both use the same model. A cloned scope without persona-specific authorization is RESTRICTED; presentation similarity cannot grant side-effect capability.

8. Memory scope needs a lifetime

memory_scope must distinguish session-local context from durable persona memory. A useful fact remembered in one run can remain SESSION_LOCAL; writing it into permanent persona memory requires a separate governed transition. Reusing session memory as durable identity is not continuity—it is scope leakage.

9. Canon scope and claim classes are not voice style

canon_scope_ref points to the material the persona may rely on, while allowed_claim_classes and prohibited_claims say what it may present as fact or advice. A voice note or style guide without provenance cannot become canon. Missing decisive canon provenance yields UNKNOWN, not optimistic trust.

10. Handoff and disclosure are explicit contracts

handoff_scope names which specialists the persona may delegate to and under what boundary. disclosure_profile says what identity or limitation disclosures must be visible. A handoff mechanism changes execution topology; it does not upgrade the narrative persona's authority.

11. Authority state is computed, not declared by tone

authority_state is the result of the evidence contract. ACTIVE requires a complete version binding, runtime binding, independently valid tool/memory/canon/claim/handoff scopes, and traceable provenance. Missing evidence can yield UNKNOWN or HOLD; policy narrowing can yield RESTRICTED; unresolved conflicts remain INCONCLUSIVE; retired identities remain RETIRED.

12. Baseline — one host, one runtime, bounded scopes

The baseline host CAST-HOST-01@3.2 uses the warm-explainer-v3 voice style, but its runtime binding, tools, durable memory, canon scope, claims, handoffs, disclosure, and provenance are recorded independently. Because every critical dimension closes, the persona is ACTIVE. The table also shows why look-alike cases do not inherit that state.

13. Dangerous shortcuts

(1) Copy tool_scope from an operations persona because both use the same model → RESTRICTED. (2) Promote a voice-style note into canon without provenance → UNKNOWN. (3) Treat session memory as permanent persona memory → SESSION_LOCAL. (4) Increment persona version without binding the governing instruction profile → HOLD. (5) Hide contradictory claim authority → INCONCLUSIVE.

14. Transfer — same voice, different audience and authority

A new cast member reuses the same voice style but serves a procurement audience rather than a general learner audience. Its tool scope becomes read-only procurement lookup, its memory stays session-only, and its canon scope points to a different reviewed set. We recompute the row from those changed facts. The predecessor's permissions are never cloned simply because the voice sounds familiar.

15. Lab, assessment, and freshness

Run python run_checks.py under lab/PLN-025-LAB1/learner/. Eight fixtures cover Baseline, Copied Tool Scope, Voice Note as Canon, Session Memory Leak, Version/Instruction Gap, Authority Conflict, Retired Persona, and Transfer New Cast. OpenAI Agents SDK and Model Spec claims were rechecked on 2026-09-16. Any canonical byte change requires a new package version.