Stale Slot Detection Prompt Template

This prompt is designed for long-running assistant sessions where user-provided information can become invalid over time. The core job-to-be-done is to programmatically identify previously captured slot values—such as an account number, a date range, or a product name—that may no longer be reliable due to explicit user corrections, topic shifts, or the passage of time. The ideal user is an AI engineer or product developer building a copilot, support agent, or form-filling assistant that persists state across many turns. You need this prompt when your application maintains a structured dialogue state and you must decide which fields to re-verify before taking an action, rather than blindly trusting stale context.

Use this prompt when your session state object contains more than a handful of slots and the cost of acting on a wrong value is high—for example, querying a database with an outdated customer ID, booking a service for a date the user already changed, or summarizing preferences the user has since contradicted. The prompt expects two structured inputs: a current slot state JSON object and a recent conversation history. It outputs a list of suspect slots, each with a staleness reason and a suggested re-verification trigger. Do not use this prompt for real-time, single-turn extraction where no prior state exists; that is a job for the Dialogue Slot Extraction Prompt Template. Do not use it as a replacement for a full state validation pass—it is a targeted staleness detector, not a schema validator.

Before wiring this into production, define clear thresholds for what counts as 'stale' in your domain. A slot captured 20 turns ago in a fast-moving troubleshooting session may be stale, while the same slot in a slow, deliberate account review may still be valid. Pair this prompt with a re-verification action: when the prompt flags a slot, your harness should either ask the user a targeted clarification question or suppress the slot from downstream tool calls until it is refreshed. Never silently discard a slot based solely on the model's staleness classification—always route suspect slots through a confirmation or re-extraction step. The next section provides the copy-ready prompt template you can adapt to your slot schema and staleness rules.

This prompt template detects slot values that may have become invalid due to explicit user corrections, topic shifts, or elapsed time. It is designed for copilot and assistant systems where user information evolves across turns—such as changing an account number, updating a shipping address, or revising a preference mid-session. The template expects a structured slot schema, the full conversation history, and a set of staleness rules. It outputs a list of suspect slots with re-verification triggers, enabling your application to proactively confirm or refresh stale data before acting on it.

textCopy
You are a dialogue state auditor. Your task is to examine the conversation history and identify previously captured slot values that may now be stale or invalid.

## SLOT SCHEMA
[SLOT_SCHEMA]

## CONVERSATION HISTORY
[CONVERSATION_HISTORY]

## STALENESS RULES
[STALENESS_RULES]

## INSTRUCTIONS
1. Review each slot in the schema against the full conversation history.
2. For each slot, determine whether its current value is still valid based on the staleness rules.
3. A slot is considered stale if:
   - The user explicitly corrected or contradicted a previously stated value.
   - The conversation topic shifted to a new context that invalidates prior values (e.g., switching from one account to another).
   - The slot value was provided more than [MAX_SLOT_AGE_TURNS] turns ago and has not been reconfirmed.
   - The slot depends on another stale slot (cascading staleness).
4. For each stale slot, provide:
   - The slot name.
   - The current (suspect) value.
   - The reason for staleness (correction, topic shift, age, dependency).
   - A suggested re-verification question to ask the user.
   - The turn number where the value was last confirmed.
5. Do NOT mark a slot as stale if the user has explicitly reconfirmed it within the staleness window.
6. If no slots are stale, return an empty list.

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "stale_slots": [
    {
      "slot_name": "string",
      "current_value": "string or null",
      "staleness_reason": "correction | topic_shift | age | dependency",
      "evidence_turn": integer,
      "re_verification_question": "string"
    }
  ],
  "analysis_summary": "string"
}

## CONSTRAINTS
- Only use information present in the conversation history. Do not invent values.
- If the staleness reason is ambiguous, default to marking the slot as suspect and flag it for human review if [RISK_LEVEL] is 'high'.
- Do not exceed the output schema. No additional commentary outside the JSON object.

To adapt this template for your application, replace the square-bracket placeholders with your specific configuration. [SLOT_SCHEMA] should contain a JSON schema or structured list of slot names, types, and descriptions that your system tracks. [CONVERSATION_HISTORY] should include the full turn history with speaker labels and turn numbers. [STALENESS_RULES] can be customized with domain-specific rules—for example, financial applications might add a rule that account numbers stale after any mention of 'fraud' or 'dispute'. [MAX_SLOT_AGE_TURNS] controls how many turns a value can persist without reconfirmation; set this based on your average session length and user tolerance for re-asking. [RISK_LEVEL] should be set to 'high' for regulated domains like healthcare or finance, which triggers the human-review flag for ambiguous cases. After generating the output, validate the JSON structure before passing it to your re-verification workflow. For high-risk deployments, log every staleness detection with the evidence turn for auditability and run periodic evaluations against a labeled dataset of known stale and valid slot states.

The stale slot detection prompt is not a standalone utility—it is a state-inspection step that should be wired into a larger dialogue management pipeline. In practice, this prompt runs after every user turn (or every N turns, depending on your latency budget) and before any downstream slot-filling or action-execution logic. The harness must supply the current slot state, the recent conversation history, and a configurable staleness threshold. The output is a list of suspect slots with re-verification triggers, which your application should use to either re-prompt the user, re-run extraction against fresh context, or escalate for human review if the slot is critical.

Integration pattern: Place this prompt as a pre-processing step in your turn-handling loop. The typical flow is: (1) receive user input, (2) append to conversation history, (3) run stale slot detection with the current slot state and history, (4) for each flagged slot, either mark it as needs_reverification in your state store or immediately trigger a clarification sub-dialogue, (5) proceed with normal slot extraction and intent handling only after stale slots are resolved. Validation: The harness must validate that every flagged slot actually exists in the input slot state—hallucinated slot names are a known failure mode. Use a strict schema check: if the model returns a slot key not present in the input, discard that flag and log the anomaly. Retries: If the output fails schema validation or returns a malformed JSON structure, retry once with a simplified prompt that includes the validation error message. If the retry also fails, default to treating all slots as potentially stale and trigger a lightweight confirmation step rather than blocking the conversation.

Model choice and latency: This is a classification-and-extraction task that benefits from models with strong instruction-following and structured output capabilities. For production, prefer a fast model (e.g., Claude Haiku, GPT-4o-mini, or a fine-tuned smaller model) because this prompt runs on every turn and latency compounds. If your slot state is large, consider chunking: run detection on subsets of slots grouped by domain or recency, then merge results. Logging and observability: Log every stale slot detection result with the input slot state hash, the conversation turn count, the flagged slots, and the re-verification triggers. This trace is essential for debugging false positives (slots flagged as stale when they are still valid) and false negatives (stale slots that were missed and caused downstream errors). Set up a dashboard alert if the stale flag rate suddenly spikes, as this often indicates a context pollution bug or a model behavior change.

Human review gate: For high-risk domains—healthcare, finance, legal—do not automatically discard or overwrite slot values based solely on the model's staleness flag. Instead, route flagged slots to a review queue where a human confirms the re-verification trigger before the slot is invalidated. For lower-risk applications, you can automate re-verification by re-running slot extraction against the recent conversation turns, but always compare the new value against the old value and log the diff. What to avoid: Do not use this prompt as the sole mechanism for slot correctness. It detects likely staleness, not guaranteed staleness. Always pair it with explicit user confirmation for critical slots and with timestamp-based expiry as a fallback for slots that haven't been referenced in N turns.