Session Rollback Prompt for Error Recovery

This prompt is designed for platform teams operating persistent chat products where a corrupted conversation state must be surgically rewound to a known-good point. The primary job-to-be-done is automated state recovery: when an assistant hallucinates a critical fact, a tool call returns a fatal error that poisons the dialogue context, or a cascade of user corrections renders the recent turn history unreliable, this prompt analyzes the full turn log to identify the last stable state. It then produces a structured rollback plan specifying which turns to discard and a user-facing message that transparently resets the conversation without forcing the user to repeat their original intent. The ideal user is an AI reliability engineer or backend developer integrating this prompt into a state management harness that can programmatically rewind a session's turn index.

Deploy this prompt when your application maintains a turn-by-turn conversation log with unique identifiers and supports rewinding state to a specific turn index. The trigger condition is typically a downstream validation failure, a tool error response code, or a user signal indicating the assistant has gone off-track (e.g., 'That's completely wrong, let me start over from my last point'). The prompt requires the full conversation log, the error context, and the user's last explicit correction as inputs. It is not a general error handler for system-level failures like network timeouts, authentication errors, or rate limiting—those belong in your application's exception handling layer, not in a language model prompt. Using this prompt for transient infrastructure errors will produce unnecessary state rollbacks and a confusing user experience.

Before wiring this into production, ensure your application can execute the rollback plan atomically: discard the specified turns, restore the assistant's internal state to the target turn index, and inject the generated user-facing message as the next assistant response. The prompt's output must be validated for structural completeness—specifically, the target turn index must exist in the provided log and the discarded turn count must be non-zero. In high-stakes domains such as healthcare or finance, always route the rollback plan through a human review queue before execution. Do not use this prompt for conversations shorter than three turns, as there is insufficient history for a meaningful rollback, and a simple 'Let's start over' reset is more appropriate.

This prompt template identifies the last known-good state in a conversation, determines which turns and context to discard, and produces a structured rollback plan with user-facing communication. It is designed for production chat systems where a model error, tool failure, or correction cascade has corrupted the dialogue state and you need a reliable recovery path. The prompt assumes you have access to the full conversation history, system instructions, and any structured state you maintain outside the prompt.

textCopy
You are a conversation state recovery specialist. Your task is to analyze a corrupted conversation and produce a rollback plan.

## INPUT
- Full conversation history: [CONVERSATION_HISTORY]
- System instructions: [SYSTEM_INSTRUCTIONS]
- Structured session state (slots, pending actions, unresolved questions): [SESSION_STATE]
- Error description or correction cascade summary: [ERROR_DESCRIPTION]
- User's last explicit intent before the error cascade began: [USER_INTENT]

## TASK
1. Identify the last known-good turn index where the conversation was coherent and on-track.
2. Determine which turns, state entries, and context must be discarded.
3. Produce a rollback plan that includes:
   - `rollback_turn_index`: integer, the last turn to keep
   - `discarded_turns`: array of turn indices to remove
   - `state_repairs`: object mapping state keys to corrected values (null means delete the key)
   - `recovery_message`: string, what to say to the user to acknowledge the error and resume
   - `resume_context`: string, a compressed summary of the conversation up to the rollback point that the assistant should carry forward
   - `confidence`: float 0-1, how confident you are in this rollback point
4. If no clear good state exists, set `rollback_turn_index` to -1 and `recovery_message` to a full restart acknowledgment.

## CONSTRAINTS
- Do not discard turns that contain user decisions, confirmations, or critical information unless they are provably part of the error cascade.
- The recovery message must be honest about the error without exposing internal system details.
- Preserve pending actions and unresolved questions that predate the error.
- If the error cascade started after a tool call failure, verify whether the tool result was corrupted or the call itself was invalid.

## OUTPUT_SCHEMA
Return valid JSON matching this schema:
{
  "rollback_turn_index": integer,
  "discarded_turns": [integer],
  "state_repairs": { "key": "value_or_null" },
  "recovery_message": "string",
  "resume_context": "string",
  "confidence": float,
  "rationale": "string explaining the rollback decision"
}

Adapt this template by replacing the square-bracket placeholders with your actual conversation data. [CONVERSATION_HISTORY] should include the full turn-by-turn dialogue with speaker labels and turn indices. [SESSION_STATE] should contain your structured state object—slots, pending actions, unresolved questions, and any active constraints. If your system does not maintain structured state outside the prompt, omit that field or pass an empty object. [ERROR_DESCRIPTION] should describe what went wrong: a model hallucination, a tool failure, a correction cascade, or an internal error. [USER_INTENT] should capture the user's last clear goal before things went off track. If your model provider supports structured output mode, use the OUTPUT_SCHEMA directly. Otherwise, append the schema instructions at the end of the prompt and parse the JSON from the model's response. Validate the output before applying the rollback: check that rollback_turn_index is within bounds, discarded_turns does not include the rollback point, and state_repairs keys match your actual state schema. For high-stakes conversations, route rollback plans with confidence below 0.7 to human review before executing the state repair.

The Session Rollback Prompt is not a standalone chat interaction—it is a state-repair function that your application calls when error recovery logic detects a correction cascade, tool failure, or user pushback that invalidates recent conversation turns. The prompt expects structured inputs: the full conversation history, an error description, and optionally the last known-good turn index. Your application must assemble these inputs from your conversation store before invoking the model. Treat this prompt as a deterministic recovery step with a structured output contract, not as an open-ended assistant response.

Input assembly: Before calling the prompt, your harness must retrieve the conversation history from your session store and serialize it into a turn-by-turn format with speaker labels (user, assistant, system), turn indices, and timestamps. Include tool call results and any structured state snapshots that were active before the error. The [ERROR_DESCRIPTION] placeholder should contain a machine-generated summary of what went wrong—such as a tool timeout, a validator rejection, or a user correction flag—rather than raw error logs. If your system tracks a last_known_good_turn_index, pass it explicitly; otherwise, set it to null and let the model infer the rollback point. Output validation: The prompt returns a JSON object with rollback_target_turn_index, turns_to_discard, state_repair_actions, and user_message. Your harness must validate that rollback_target_turn_index is an integer less than the current conversation length and that turns_to_discard is a positive integer. If validation fails, retry once with the validation error appended to the [ERROR_DESCRIPTION] field. After two failures, escalate to a human operator with the conversation context and validation trace.

State application: After validation passes, your harness must execute the rollback programmatically—not by asking the model to continue the conversation. Truncate the conversation history at rollback_target_turn_index, apply any state_repair_actions to your structured dialogue state (e.g., resetting slot values, clearing pending actions, restoring prior constraints), and surface the user_message to the end user as a system-generated acknowledgment. Logging and audit: Write a rollback event to your audit trail with the pre-rollback turn count, the rollback target, the error trigger, and the model's rationale. This is critical for debugging rollback loops and for compliance workflows that require traceable state changes. Model choice: Use a model with strong instruction-following and JSON output discipline—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Avoid smaller or older models that may hallucinate turn indices or produce malformed JSON under recovery pressure. What to avoid: Do not use this prompt inside a retry loop without a maximum retry cap. Do not apply rollback actions without validating the target index against your actual conversation store. And do not skip the audit log—rollback events are the first place you will look when users report lost context or repeated assistant mistakes.