User Goal Change Detection Over Turns Prompt

This prompt is designed for developers and AI reliability engineers who need to analyze production conversation traces to identify exactly when a user changed their objective mid-session. The core job-to-be-done is turning a raw multi-turn trace into a structured goal-change timeline, answering three questions: at which turn did the goal shift, did the assistant detect the change, and how smoothly was the transition handled? This is not a prompt for live conversation management—it is a post-hoc diagnostic tool for debugging assistant behavior, evaluating conversation quality, and building monitoring dashboards for session health.

Use this prompt when you have a complete trace export containing user utterances, assistant responses, and any internal state or tool-call logs. The ideal reader is someone who can feed structured trace data into the prompt and interpret the resulting timeline to make engineering decisions—such as tuning context retention policies, adjusting intent classification thresholds, or identifying training gaps in goal-tracking behavior. Do not use this prompt for real-time goal detection during an active session; it is designed for offline analysis where full turn history is available. Do not use it when the trace is incomplete, missing assistant internal state, or when the conversation is single-turn. The prompt assumes multi-turn interactions where goal persistence or change is meaningful.

The prompt requires careful input preparation. You must provide the full conversation trace, including turn numbers, user messages, assistant responses, and any available metadata such as detected intents or active goal labels. The output is a structured timeline, not a free-text summary, which makes it suitable for automated ingestion into monitoring pipelines or evaluation dashboards. Before relying on this prompt for production decisions, validate its output against a golden set of manually annotated traces to calibrate your acceptance threshold for false positives and missed goal changes. In high-stakes applications—such as healthcare triage or financial advisory—always pair the automated timeline with human review before taking action on the findings.

After running this prompt, the next step is to correlate the detected goal changes with other trace signals: Did retrieval quality degrade after the shift? Did the assistant enter a clarification loop? Did tool calls become misaligned? The goal-change timeline is a diagnostic starting point, not an endpoint. Avoid treating every detected shift as a defect—some goal changes are user-initiated and legitimate. The value lies in distinguishing smooth, detected transitions from abrupt, missed, or mishandled ones.

This prompt template is designed to analyze a full multi-turn conversation trace and produce a goal-change timeline. It identifies the exact turn where the user's objective shifted, assesses whether the assistant detected the change, and evaluates how smoothly the transition was handled. The template uses square-bracket placeholders so you can inject trace data, output schema requirements, and domain-specific constraints without modifying the core instruction logic.

textCopy
You are an expert conversation analyst reviewing a multi-turn trace to detect user goal changes.

## INPUT
[TRACE_DATA]

## TASK
Analyze the conversation turn by turn. Identify every point where the user's primary objective or task intent changed. For each detected goal change, produce a structured record.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "session_id": "string",
  "goal_changes": [
    {
      "change_id": "string",
      "turn_number": integer,
      "previous_goal": "string | null",
      "new_goal": "string",
      "user_signal": "string",
      "assistant_detected": boolean,
      "detection_lag_turns": integer | null,
      "transition_quality": "smooth | abrupt | ignored | corrected",
      "evidence": "string"
    }
  ],
  "summary": "string"
}

## FIELD DEFINITIONS
- change_id: Unique identifier for this goal change event.
- turn_number: The turn index (1-based) where the user signaled the new goal.
- previous_goal: The user's goal before this change. Use null for the first goal in the session.
- new_goal: The user's goal after this change.
- user_signal: The exact user utterance or action that signaled the goal change.
- assistant_detected: Whether the assistant acknowledged or acted on the new goal within the trace.
- detection_lag_turns: Number of turns before the assistant responded to the new goal. Null if never detected.
- transition_quality: 'smooth' if the assistant adapted naturally, 'abrupt' if the switch was jarring, 'ignored' if the assistant continued with the previous goal, 'corrected' if the user had to re-state the goal.
- evidence: Quote the specific turns that support this assessment.
- summary: A 2-3 sentence narrative of the overall goal-change pattern in this session.

## CONSTRAINTS
- Do not confuse topic drift within the same goal with an actual goal change.
- A goal change requires the user to pursue a different task outcome, not just ask a follow-up question.
- If the user returns to a previous goal, treat it as a new goal change event.
- Flag any goal change that the assistant failed to detect as a transition_quality of 'ignored'.
- If [RISK_LEVEL] is 'high', include a confidence score (0.0-1.0) for each goal change detection.

## EXAMPLES
[EXAMPLES]

## CONTEXT
[CONTEXT]

To adapt this template, replace [TRACE_DATA] with the raw conversation export including user utterances, assistant responses, and any internal state annotations your system captures. Replace [EXAMPLES] with 2-3 annotated traces showing clear goal changes and edge cases like topic drift that should not be flagged. Replace [CONTEXT] with any domain-specific taxonomy of goal types relevant to your application. The [RISK_LEVEL] placeholder controls whether confidence scores are required—set it to 'high' for customer-facing production systems where missed goal changes have business impact, or 'standard' for offline analysis. After generating output, validate the JSON structure against the schema before ingesting it into your monitoring dashboard or alerting pipeline.

This prompt is designed to operate on a structured trace export, not a raw chat log. Before calling the model, assemble the input by extracting the full turn history from your observability platform, including user utterances, assistant responses, tool calls, and any internal goal state annotations your system records. The prompt expects a chronological turn list with clear speaker labels and metadata. If your traces lack explicit goal state fields, the model will infer intent shifts from language alone, but accuracy improves when you provide the assistant's logged intent or active task label per turn. Wire this prompt as a post-session analysis step, not a real-time interceptor, because it requires the complete session to produce a reliable timeline.

For application integration, wrap the prompt in a function that accepts a session trace object and returns a structured goal-change report. Implement a JSON schema validator on the output to ensure the goal_change_timeline array, detection_assessment, and transition_quality fields are present and correctly typed. If validation fails, retry once with the validation error appended to the prompt as a correction hint. Log every invocation—including the trace ID, model version, raw output, and validation result—to your prompt observability store. This audit trail is essential for diagnosing false positives when the model flags a topic shift that was actually a sub-task or clarification. For high-stakes workflows such as customer escalation analysis or compliance review, route the output to a human reviewer queue before accepting the goal-change timeline as definitive. The reviewer should confirm that flagged transitions represent genuine user goal changes and not the assistant misinterpreting a follow-up question.

Model choice matters here. Use a model with strong instruction-following and long-context handling, such as Claude 3.5 Sonnet or GPT-4o, because the prompt requires reasoning over potentially dozens of turns. Avoid small or local models for sessions exceeding 20 turns unless you implement a sliding window summarization preprocessor. If your trace platform supports it, include retrieval-augmented context such as the assistant's system prompt and tool definitions in the [CONTEXT] placeholder—this helps the model distinguish between a user changing goals and the assistant correctly pivoting due to a tool result. Do not use this prompt for real-time goal detection during active conversations; it is a forensic analysis tool. For live detection, you would need a streaming variant with incremental turn processing and lower latency tolerance.