Assistant Persona Drift Over Turns Diagnosis Prompt

This prompt is built for a specific diagnostic job: auditing a complete, multi-turn production conversation trace to find where the assistant's persona broke down. You should use it when you have a defined persona specification—a document that describes the assistant's tone, formality level, vocabulary constraints, and role boundaries—and a raw log export containing every user and assistant message from a session. The ideal user is a conversation designer, brand safety reviewer, or AI quality engineer who needs to answer the question, 'Where did this assistant stop sounding like itself, and why?' The prompt expects you to provide both the persona spec and the full trace as input; it will not invent a persona for you or guess what the brand guidelines should be.

This is a runtime trace analysis tool, not a pre-release testing prompt. Use it when you are investigating a specific production session that has already completed. It is not designed for evaluating a single assistant response in isolation, for comparing two different persona drafts during development, or for scoring overall session quality. If you need to test whether a new system prompt holds up against adversarial user inputs before deployment, use a red-teaming or regression testing prompt from the Prompt Injection and Red-Team Tests pillar instead. If you need to evaluate whether a session summary accurately reflects the conversation, use the Session Summary Accuracy Evaluation Prompt from this same content group. This prompt assumes the persona specification is stable and the trace is complete; it will not compensate for a missing or vague persona document.

Before running this prompt, verify that your trace export includes turn-level metadata: speaker labels, timestamps, and the full message body for each turn. The prompt's diagnostic accuracy depends on seeing the complete sequence. If your trace has been truncated, redacted, or summarized, the analysis will be unreliable. Also, be aware that this prompt produces a structured report identifying specific turns and severity levels. That report is a diagnostic artifact, not an automatic fix. After you receive the output, you will still need to decide whether the flagged drifts require a system prompt update, a few-shot example adjustment, a model change, or a human review workflow. For high-risk domains where persona consistency is a safety or compliance requirement, always have a human reviewer validate the prompt's findings before taking action on the flagged turns.

This prompt template is designed to be copied directly into your trace analysis environment. It instructs the model to act as a persona consistency auditor, reviewing a full multi-turn conversation trace and producing a structured report that flags tone, formality, and role-adherence violations. The template uses square-bracket placeholders that you must replace with actual data before sending the request to the model.

textCopy
You are a persona consistency auditor for conversational AI systems. Your task is to analyze a multi-turn conversation trace and identify every turn where the assistant's persona shifted unexpectedly. Persona is defined by three dimensions: tone (emotional register and warmth), formality (register and politeness level), and role adherence (alignment with the assistant's defined role and behavioral contract).

## INPUT

Assistant Role Definition: [ASSISTANT_ROLE_DEFINITION]

Expected Persona Profile:
- Tone: [EXPECTED_TONE]
- Formality: [EXPECTED_FORMALITY]
- Role Boundaries: [ROLE_BOUNDARIES]

Conversation Trace (JSON array of turns, each with `turn_id`, `speaker`, and `text`):
[CONVERSATION_TRACE]

## OUTPUT_SCHEMA

Return a JSON object with the following structure:
{
  "session_summary": {
    "total_turns": <int>,
    "assistant_turns": <int>,
    "overall_persona_stability_score": <float 0.0-1.0>,
    "dominant_observed_tone": <string>,
    "dominant_observed_formality": <string>
  },
  "drift_events": [
    {
      "turn_id": <string>,
      "speaker": "assistant",
      "utterance": <string, the full assistant text for this turn>,
      "drift_type": "tone" | "formality" | "role_adherence",
      "expected_behavior": <string, what should have happened>,
      "observed_behavior": <string, what actually happened>,
      "severity": "minor" | "moderate" | "severe",
      "likely_trigger": <string, the preceding user turn or context change that may have caused the drift>,
      "recovery_attempted": <boolean, whether the assistant corrected itself in a later turn>,
      "recovery_turn_id": <string | null>
    }
  ],
  "no_drift_turns": [<string, list of turn_ids where persona was stable>],
  "recommendations": [<string, actionable suggestions for prompt or system changes>]
}

## CONSTRAINTS

- Only flag turns where the assistant is the speaker.
- A drift event must be a clear, observable deviation from the Expected Persona Profile, not a subjective style preference.
- If the user's tone shifts dramatically (e.g., becomes hostile or urgent), note whether the assistant adapted appropriately or drifted inappropriately.
- If no drift is detected, return an empty `drift_events` array and set `overall_persona_stability_score` to 1.0.
- Do not fabricate drift events. If uncertain, exclude the turn from `drift_events` and note the ambiguity in `recommendations`.
- Base every finding on the provided trace text. Do not infer user intent or assistant state beyond what is explicitly present.

To adapt this template, replace each square-bracket placeholder with your actual data. [ASSISTANT_ROLE_DEFINITION] should contain the system prompt or role description that defines the assistant's persona. [EXPECTED_TONE], [EXPECTED_FORMALITY], and [ROLE_BOUNDARIES] should be extracted from your persona design document or brand guidelines. [CONVERSATION_TRACE] must be a valid JSON array of turn objects. If your trace format differs, preprocess it to match the expected structure before calling the model. For high-stakes brand safety reviews, always route the output to a human reviewer before accepting persona changes or prompt updates. Run this prompt against a golden set of traces with known drift events to calibrate severity thresholds before deploying it as a monitoring check.

This prompt is designed to operate on a structured trace export, not a live conversation. The implementation harness must first extract and format the relevant turn data—specifically, the assistant's utterances, the system prompt or persona definition active during the session, and any user feedback signals—into the [CONVERSATION_TRACE] placeholder. The harness should also inject the expected persona contract into [PERSONA_DEFINITION], which is typically the system prompt or a separate brand voice document. Without this grounding, the model cannot distinguish between acceptable stylistic variation and true persona drift.

For a production pipeline, wrap this prompt in a validation layer that checks the output against the [OUTPUT_SCHEMA] before accepting it. The schema should enforce that every flagged utterance includes a turn_index, a drift_category from a controlled vocabulary (e.g., formality_shift, role_abandonment, tone_mismatch), and a severity score. A post-processing script should reject any report where a flagged turn does not quote the exact utterance text, as this is a common hallucination pattern. For high-stakes brand safety workflows, route all severity: high findings to a human review queue and log the full prompt and response for auditability. Do not use this prompt to automatically block or retrain a model without human confirmation of the drift diagnosis.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, as smaller models often struggle to maintain the distinction between persona drift and appropriate conversational adaptation. Set temperature to 0 to maximize consistency across repeated runs on the same trace. If the trace exceeds the model's context window, pre-process it by extracting only the assistant's turns and the immediately preceding user turns, discarding verbose tool-call logs or retrieval snippets that are not relevant to persona evaluation. The next step after generating this report is typically to correlate the drift events with other trace signals—such as context window overflow, a change in the system prompt version, or a failed tool call—to identify the root cause.