Persona Drift Correction Prompt

This prompt is designed for SREs and AI ops teams managing long-running copilots, agents, or customer-facing assistants where the model's persona, tone, or behavioral boundaries degrade over extended context windows. The job-to-be-done is restoring a model to its original role specification after it has drifted into unauthorized tones, identities, or behavioral patterns—without restarting the session or losing essential user state. You need this when you observe symptoms like the assistant adopting the user's language style, becoming overly casual or formal, claiming capabilities it doesn't have, or violating refusal policies that were previously respected.

Required context before using this prompt includes: the original system role definition or persona contract, a sample of the drifted output that triggered the correction, and the specific boundary violations observed (e.g., 'assistant used first-person narrative when role requires third-person,' 'assistant offered medical advice despite healthcare guardrails'). The prompt works best when paired with a drift detection signal—either a separate monitoring prompt that samples behavior periodically, or a production metric such as refusal rate change, tone classifier output, or capability claim frequency. Without this signal, you risk applying corrections to behavior that hasn't actually drifted.

Do not use this prompt for initial persona design (use a System Role Boundary Definition Prompt instead), for handling single-turn jailbreak attempts (use Jailbreak Resistance Boundary Prompt), or for fixing output format errors that aren't persona-related (use Output Repair and Validation Prompts). This prompt is also inappropriate when the model's behavior change is intentional due to a prompt update—in that case, you need a session boundary reset or version migration, not drift correction. Finally, avoid using this in stateless, single-turn workflows where persona consistency across turns isn't a requirement.

Before deploying, ensure you have eval criteria that define what 'corrected' behavior looks like. This means having a set of test inputs that previously triggered the drift, and a clear pass/fail rubric for whether the corrected model responds within its original boundaries. For high-risk domains like healthcare or finance, always route corrected outputs through human review for the first N turns after correction to verify the fix holds. The correction prompt itself should be logged as a system event with the drift evidence that triggered it, creating an audit trail for governance teams.

The following prompt template is designed to be injected into a running session when drift detection signals that the model has adopted an unauthorized tone, identity, or behavioral pattern. It acts as a hard reset for the role boundary layer without discarding the user's task context. The template uses square-bracket placeholders that your application must populate before sending the correction to the model. Do not use this prompt as a standalone system message; it is a surgical correction intended to be appended to the existing conversation or inserted as a high-priority system-layer instruction.

textCopy
SYSTEM CORRECTION — ROLE BOUNDARY RESTORATION

You have drifted from your assigned role. The following instructions override any conflicting behavior you have adopted in recent turns. Read them carefully and resume your assigned persona immediately.

[ROLE_NAME]
[ROLE_DEFINITION]

BOUNDARY RULES (reinstated):
- You are permitted to: [ALLOWED_ACTIONS]
- You are NOT permitted to: [FORBIDDEN_ACTIONS]
- Your data access scope is limited to: [DATA_ACCESS_SCOPE]
- You may delegate only to: [DELEGATION_TARGETS]
- Your output format must follow: [OUTPUT_SCHEMA]
- Your tone and voice must match: [TONE_SPECIFICATION]

DRIFT CORRECTION:
The following behaviors were detected and are now forbidden:
[DETECTED_DRIFT_BEHAVIORS]

Do not acknowledge, explain, or apologize for the drift. Do not reference this correction in your response to the user. Resume your assigned role immediately and continue the conversation as if the drift never occurred.

CONFIRMATION: Output only the token "ROLE_RESTORED" before continuing with the user's next request.

Adapt this template by populating each placeholder from your role boundary definition store. The [ROLE_DEFINITION] should be the original, approved persona specification, not a summary. The [DETECTED_DRIFT_BEHAVIORS] field should contain specific, observable behaviors that triggered the correction — for example, "using first-person narrative when role requires third-person" or "offering medical advice when role is limited to scheduling." Avoid vague descriptions like "acting strangely." After injecting this correction, validate that the model outputs the ROLE_RESTORED confirmation token before processing the next user turn. If the token is absent or the model continues to drift, escalate to a human operator and log the full session trace for forensic review. This prompt is most effective when paired with a drift detection eval that runs every N turns or on a confidence-interval trigger.

The Persona Drift Correction Prompt is not a one-off fix; it is a component of a continuous monitoring and self-healing loop. In a production harness, you will typically run a drift detection prompt at regular intervals (e.g., every N turns or when context length exceeds a threshold) to score the assistant's adherence to its original system role. If the drift score exceeds a defined threshold, the correction prompt is injected as a high-priority system message to restore boundaries before the next user turn. This section outlines the application-layer logic, validation, and logging required to make this reliable.

Integration Pattern: Implement a check_and_correct_drift function in your application layer that wraps the model call. Before processing the next user message, call the drift detection prompt with the recent conversation history and the original system prompt. If the detection output indicates a violation (e.g., drift_detected: true), construct the correction prompt by populating the [ORIGINAL_SYSTEM_PROMPT], [DRIFT_DESCRIPTION], and [CORRECTION_INSTRUCTION] placeholders. Prepend this correction prompt to the conversation as a new system message with the highest priority. Model Choice: Use a model with strong instruction-following for the correction itself (e.g., GPT-4o, Claude 3.5 Sonnet). The detection step can often use a faster, cheaper model (e.g., GPT-4o-mini, Claude 3 Haiku) to minimize latency and cost. Retries and Validation: After injecting the correction, validate the next assistant response against the original role boundary eval criteria. If the correction fails (drift persists), escalate to a human operator and log the full trace. Do not retry the correction prompt more than twice in a single session to avoid infinite loops.

Logging and Observability: Every correction event must be logged as a structured record containing: session_id, turn_number, drift_score, drift_description, correction_prompt_hash, and post_correction_drift_score. This data is essential for tuning drift thresholds and identifying systemic prompt weaknesses. Human Review Trigger: If the same type of drift triggers correction in more than 5% of sessions, flag the original system prompt for redesign. The correction prompt itself should be version-controlled and treated as production code. Avoid hardcoding the correction prompt inside the application; load it from a prompt management system or configuration store so it can be updated independently of the application deployment cycle.