Runbook — Persona Rollback

Revert a Lilith-controlled persona version that has produced identity drift, tone violation, disclosure failure, or refusal-policy regression in production. Persona versions are tightly bound to Lilith policy and AI-disclosure compliance; a persona rollback always involves T&S.

Scope#

Triggers:

• Persona identity drift — customer-visible persona does not match its certified identity (name, voice, body of memory, allowed topics).
• Tone regression — persona drifts off the certified tone policy (excessively casual, off-brand, inconsistent with persona archetype).
• Disclosure failure — AI-disclosure copy missing, mistimed, or rendered in the wrong locale.
• Refusal regression — refusal class fires incorrectly (false positive) or fails to fire when it should (false negative).
• Memory binding regression — persona retrieves memory from the wrong scope (cross-persona or cross-tenant).
• Voice or avatar identity mismatch — persona voice/avatar diverges from its certified lineage.

This is a focused subtype of model-workflow-rollback.md. The persona runbook owns the customer-disclosure and T&S coordination steps; the model runbook handles general model-version rollback procedure.

Severity classification#

Source events: assistant.persona.identity_confirmed, assistant.persona.disclosure_shown, assistant.persona.refusal_applied, admin.persona.promoted, admin.persona.rolled_back.

Detection signals#

• Alerts: persona-policy-violation.
• Dashboards: persona panels on dashboards-assistant.ts — identity confirmation rate, disclosure render rate, refusal class breakdown, tone evaluation rolling average.
• Customer signals: spike in assistant.persona.identity_disputed_by_user, assistant.disclosure.banner_dismissed_rapidly.
• Admin signals: T&S queue review.persona.appeal or review.persona.identity_complaint.

Rollback procedure#

1. Identify the certified prior version: read release-taxonomy.ts for the persona target. The previous admin.persona.certified record is the rollback destination.
2. Confirm joint baseline with the underlying LLM: each certified persona is bound to a certified Lilith policy version and an LLM version. The rollback must move all three back together (persona, policy, LLM) — moving only the persona row creates a mismatched refusal baseline and a fresh persona-policy-violation alert.
3. Disable the current persona version: call the persona-rollback hook in release-taxonomy. The hook emits admin.persona.rolled_back with the source, destination, operator, and reason code.
4. Fallback to certified lineage: if no prior certified version exists (first persona launch), fall back to the disclosure-only mode — the persona is suspended and customer sessions see the assistant.persona.unavailable_shown event-driven banner with a reason copy block authored by T&S.
5. Invalidate persona caches: persona prompt caches, memory binding caches, and voice/avatar selection caches must be invalidated; the assistant.persona.cache_invalidated event records the operation.
6. Re-run the persona evaluation: gather the persona-evaluation run for the rolled-back version from evaluation-manifest.ts scope persona. Compare to baseline. The result is filed against the incident.

Customer-visible handling#

• Always disclose the change to active customer sessions interacting with the persona. The assistant.persona.identity_changed event renders the canonical disclosure copy from the i18n catalog (libs/oshun/i18n/) — do not improvise.
• Memory continuity: rolled-back persona reads its certified memory scope; any memory written during the regressed-version window is flagged for customer review. The customer sees the assistant.memory.regressed_window_flagged UI to accept or discard the flagged memory.
• Voice/avatar identity: if voice or avatar lineage rolled back, the identity-changed disclosure also runs through voice mode (audible disclosure) and avatar mode (visual disclosure) per the assistant fallback policy.

Communication cadence#

T&S co-authors the customer-disclosure and email copy. The status-page text never names the persona by internal version; use the customer-facing persona name only.

Escalation#

• T&S lead is the incident commander for persona rollbacks.
• For sev1 identity-confusion or safety-class bypass, page T&S, privacy (for memory implications), and legal at minute 0.
• Standard 5/5/15/30/60 escalation otherwise applies.

Recovery verification#

• Persona-evaluation scope passes thresholds against the rolled-back version.
• Refusal-class rates within ±1 sigma of the certified baseline for 60 min.
• Disclosure-render rate ≥ 99.9% on the affected surface for 60 min.
• Identity-confirmation rate recovered to baseline.
• No new assistant.persona.identity_disputed_by_user clusters for 30 min.
• Cache invalidation verified by trace-attribute sampling on the persona's prompt-cache key.

Post-incident#

• Postmortem must include: the persona version regression class (identity / tone / disclosure / refusal / memory / lineage), the joint baseline (persona + policy + LLM) before and after, the evaluation run artifacts, the customer-impact cohort estimate, and the T&S decision log.
• Update the persona evaluation fixtures to include the regressed case so the next promotion catches it.
• Update the disclosure i18n catalog if a locale-specific failure was observed.
• If memory was affected, run the privacy-impact note path from privacy-incident.md even if no exposure occurred — customer-visible memory state must be reconciled.