Topic Return and Resumption Detection Prompt

This prompt is a classification and context-selection tool for a context management pipeline, not a user-facing response generator. Its job is to detect when a user's current turn signals a return to a previously discussed topic after a digression. The output is a structured resumption signal that identifies which prior topic is being revisited, the specific context elements that should be restored, and a confidence score. This signal feeds downstream steps like retrieval, state restoration, and prompt assembly for the response model. The ideal user is an AI engineer or technical product manager building a multi-turn assistant where users naturally explore tangents and then circle back with phrases like 'going back to what I asked earlier' or 'about that pricing question.'

Use this prompt when your assistant maintains a session history that can span multiple distinct topics and you need a programmatic way to decide what context to carry forward. It is essential for copilots, support bots, and research assistants where context pollution from a digression will degrade the quality of the response. The required inputs are the user's current message and a structured representation of the conversation history, which should include turn indices and topic labels. The output is a machine-readable JSON object containing a boolean resumption flag, the index of the prior topic being resumed, a list of context elements to restore, and a confidence score. This output is not shown to the user; it is consumed by your application logic to modify the prompt for the next response model call.

Do not use this prompt for simple, single-topic sessions where digressions are unlikely or for real-time response generation. It is not a substitute for a full conversation state management system. If your application has a rigid, linear workflow where users cannot freely digress, this prompt adds unnecessary latency and cost. The primary failure mode is false positives, where a superficially similar but distinct topic is incorrectly flagged as a resumption. To mitigate this, your harness must include evaluation tests that pair the prompt with a validation step, checking that the restored context is genuinely relevant to the new user turn. For high-stakes domains like healthcare or finance, a human review step should be inserted before the restored context is used to generate a response.

This prompt template is designed to be integrated into a conversation management harness. It analyzes the current user turn against a structured summary of prior topics and the recent digression context. The goal is to produce a machine-readable signal indicating whether a topic return has occurred, which prior topic is being resumed, and what context should be restored. Use this template when your application needs to prevent context pollution from digressions and ensure that users don't have to repeat information they provided earlier in the session.

textCopy
You are a conversation state analyst. Your task is to detect when a user's current message signals a return to a previously discussed topic after a digression or topic shift.

## INPUT

[CURRENT_USER_MESSAGE]

## PRIOR TOPIC REGISTRY
A structured list of previously active topics, each with a unique ID, a summary, and key context that was established.
[PRIOR_TOPIC_REGISTRY]

## DIGRESSION CONTEXT
A summary of the conversation turns that occurred after the user left the prior topic.
[DIGRESSION_CONTEXT]

## CONSTRAINTS
- Do not flag a resumption if the current message is only superficially similar to a prior topic but is actually a new, distinct subject.
- A resumption can be explicit ("Going back to what we discussed about X...") or implicit (the user asks a follow-up question that only makes sense in the context of a prior topic).
- If no resumption is detected, the `resumed_topic_id` must be null and `context_to_restore` must be an empty array.
- Your confidence score must reflect the ambiguity of the signal. A vague pronoun without a clear referent should result in low confidence.

## OUTPUT_SCHEMA
You must produce a single JSON object with the following structure:
{
  "resumption_detected": boolean,
  "resumed_topic_id": string | null,
  "resumed_topic_label": string | null,
  "confidence": number, // 0.0 to 1.0
  "rationale": string,
  "context_to_restore": string[], // Array of key context strings from the prior topic that are relevant now
  "user_utterance_type": "explicit_resumption" | "implicit_resumption" | "no_resumption"
}

To adapt this template, start by defining your [PRIOR_TOPIC_REGISTRY] schema. This should be generated by your upstream topic detection and summarization logic. Each entry needs a stable ID, a concise label, and a list of key facts or decisions. The [DIGRESSION_CONTEXT] should be a rolling summary of the last N turns since the active topic changed. Before deploying, run this prompt against a golden eval set that includes both genuine resumptions and tricky negatives, such as a user asking about 'budget' in a new project context right after discussing 'budget' for a different project. The most common production failure mode is false positives on shared vocabulary, so your eval set should be weighted toward these cases.

This prompt is designed to be called as a stateful middleware function within a conversation loop, not as a standalone one-shot classifier. Before processing the next user turn, your application should pass the current user message, a structured representation of the last N turns, and a list of previously detected topics to the prompt. The model's output is a resumption signal that your application must parse and act on: if a prior topic is being resumed, your application should restore the relevant context (e.g., slot values, retrieved documents, or pending actions) before generating the assistant's response. If no resumption is detected, the application proceeds with the current context.

Wire the prompt into your application with a clear contract. The input should include a [CURRENT_MESSAGE] string, a [CONVERSATION_HISTORY] array of turn objects (each with role, content, and an optional topic_label), and a [PRIOR_TOPICS] array of topic summaries with unique IDs. The output must be parsed as JSON with fields: resumption_detected (boolean), resumed_topic_id (string or null), confidence (float 0-1), and rationale (string). Implement a validation layer that rejects malformed JSON, missing required fields, or confidence scores below a configurable threshold (e.g., 0.7). For high-stakes workflows where incorrect context restoration could mislead users, route low-confidence resumptions to a confirmation step: the assistant asks the user, "Are we returning to [topic summary]?" before restoring state. Log every resumption decision with the input context, model output, and final action taken for debugging and eval.

Choose a model with strong instruction-following and JSON output capabilities. For production, prefer models that support structured output modes (e.g., GPT-4o with response_format, Claude with tool use for JSON) to reduce parsing failures. Implement a retry strategy: if validation fails, retry up to two times with the error message appended to the prompt. If retries are exhausted, default to resumption_detected: false and log the failure for review. Avoid calling this prompt on every turn if latency is critical; instead, gate it behind a lightweight heuristic—only invoke resumption detection when the user message contains anaphora ("that," "it," "the previous"), explicit return language ("going back to"), or when the current topic classifier signals a topic shift. Finally, build an eval harness with curated test cases: true resumptions (user returns after digression), false resumption traps (superficially similar but distinct topics), and edge cases (user corrects a prior answer vs. resumes a prior topic). Run these evals on every prompt change before deployment.