Stale Context Detection and Removal Prompt

This prompt is for AI product builders who manage stateful, multi-turn conversations where information can become invalid over time. The core job-to-be-done is programmatic context hygiene: identifying and removing facts, decisions, or user statements from the conversation history that have been explicitly or implicitly superseded by newer turns. This is not a general summarization prompt. It is a targeted removal tool for when a user corrects themselves, changes their mind, provides updated information, or when an agent's actions make prior context irrelevant. The ideal user is an engineering lead or AI operator integrating this into a copilot, support agent, or task-oriented assistant where stale context causes the model to act on outdated instructions or contradict the user.

Use this prompt when your application maintains a rolling context window and you need a deterministic, auditable way to drop stale turns before the next inference call. It is appropriate for high-stakes workflows like customer support (a user updates their shipping address mid-conversation), coding agents (a user changes the target API endpoint), or planning agents (a user revises a constraint). The prompt requires a structured conversation log and a set of staleness rules as input. It should not be used as a substitute for a full conversation summary, for long-term memory consolidation, or for detecting topic shifts where no information is invalidated. If the goal is to compress history rather than remove invalidated facts, use a conversation summarization prompt instead.

Before implementing this prompt, ensure you have a reliable mechanism for extracting the conversation log in a structured format (e.g., a JSON array of turns with speaker roles and timestamps). The prompt's value depends on clear staleness markers: explicit corrections ('Actually, use the staging environment, not production'), temporal constraints ('That was before the Q3 data came in'), or action-based invalidation (a tool result that supersedes a prior assumption). Do not use this prompt for real-time safety filtering or to remove content for compliance reasons—those require deterministic rule-based systems, not an LLM judgment call. The next step after reading this section is to review the prompt template and adapt the staleness rules to your specific invalidation patterns.

This prompt template is designed to be inserted into your context assembly pipeline before packing the final prompt for the next model call. It takes the accumulated conversation history and a set of staleness rules, then returns a filtered version of the context with stale information removed or annotated. The goal is to prevent the model from acting on outdated facts, user corrections that have been superseded, or decisions that were explicitly reversed, without losing still-relevant context that the model needs to maintain conversational coherence.

codeCopy
SYSTEM: You are a context hygiene filter for a multi-turn AI assistant. Your job is to review the provided conversation history and identify information that has become stale, superseded, or explicitly corrected by later turns. You must preserve all information that remains relevant to the current conversation state.

[STALENESS_RULES]
- A fact is stale if a later user message explicitly corrects or contradicts it.
- A decision is stale if a later user message reverses or replaces it.
- A question is stale if the user has already received and acknowledged the answer.
- A stated preference is stale if the user later states a conflicting preference.
- Do NOT mark information as stale just because time has passed. Only explicit contradiction or correction makes information stale.
- Do NOT mark the most recent user intent or question as stale.

[CONVERSATION_HISTORY]
[CONVERSATION_HISTORY]

[OUTPUT_SCHEMA]
Return a JSON object with the following structure:
{
  "filtered_history": [
    {
      "turn_index": integer,
      "role": "user" | "assistant" | "tool",
      "content": "original content if still relevant, or [STALE: reason] if removed",
      "staleness_status": "active" | "stale",
      "staleness_reason": null | "corrected_by_turn_X" | "superseded_by_turn_X" | "reversed_by_turn_X"
    }
  ],
  "removed_count": integer,
  "staleness_summary": "Brief explanation of what was removed and why"
}

[CONSTRAINTS]
- Preserve all turns that are not explicitly stale.
- When marking a turn as stale, replace its content with a [STALE: reason] marker rather than deleting it, so the downstream model knows the information was present but is no longer valid.
- If no information is stale, return the full history unchanged with removed_count: 0.
- Do not modify the content of active turns.

Adaptation notes: Replace [STALENESS_RULES] with your domain-specific rules for what constitutes staleness. For example, in a customer support context, you might add rules about ticket status changes or resolution confirmations. Replace [CONVERSATION_HISTORY] with your actual conversation array, formatted as a JSON list of turn objects with turn_index, role, and content fields. The [OUTPUT_SCHEMA] can be adapted to match your downstream prompt assembly format. If your system uses a different staleness marker convention, adjust the [STALE: reason] format accordingly. For high-stakes domains such as healthcare or legal, add a [RISK_LEVEL] parameter that triggers a human review step when staleness is detected in critical context. Always validate the output against the schema before passing the filtered history to the next prompt assembly stage. Run eval checks that verify still-relevant facts are preserved and that the staleness detection doesn't remove context that the model needs to answer the current user query correctly.

This prompt is designed to run as a pre-inference filter before assembling the final prompt for the main model. It should be called after each user turn (or after every N turns, depending on your latency budget) to produce a list of context blocks that are safe to remove. The output is a structured JSON payload that your application must parse and act on—do not pass the raw model output directly to context deletion logic without validation.

Integration pattern: Wrap the prompt in a lightweight service or middleware function that (1) assembles the current conversation context, (2) injects it into the [CONVERSATION_CONTEXT] placeholder alongside any [STALENESS_RULES] specific to your domain, (3) calls a fast, cost-effective model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model), and (4) validates the returned JSON against a strict schema before removing any context. The schema should require: an array of removal_candidates with fields block_id, reason, and confidence (0-1); and an array of retained_blocks with a retention_justification for any block that might appear stale but should be kept. Reject any output that references block_id values not present in the input or that exceeds a maximum removal threshold (e.g., >40% of total context blocks) without escalating for human review.

Validation and safety gates: Before removing context, apply these checks: (a) Schema validation—parse the JSON and confirm all required fields are present and correctly typed. (b) ID integrity—every block_id in removal_candidates must exist in the input context; unknown IDs indicate hallucination and should trigger a retry or fallback to conservative retention. (c) Removal budget—if the model proposes removing more than your configured threshold of total context, log a warning and either cap removals to the threshold or escalate to a human reviewer. (d) Critical fact preservation—if your application maintains a list of pinned facts or decisions that must survive (e.g., user's stated goal, confirmed order details), cross-check that no block_id containing a pinned fact appears in removal_candidates. If it does, override the removal and log the conflict for prompt improvement.

Retry and fallback strategy: If validation fails (malformed JSON, schema mismatch, or ID integrity error), retry once with the same prompt plus the validation error message injected as [PREVIOUS_ERROR]. If the retry also fails, fall back to a conservative rule-based removal strategy (e.g., remove only blocks explicitly marked as corrected by the user, or blocks older than a configurable turn count). Log both the failure and the fallback decision for observability. For high-stakes applications (healthcare, legal, finance), always require human approval before removing any context that the model flags with confidence below 0.85.

Observability and iteration: Attach a trace ID to each stale-detection call and log: the number of blocks evaluated, the number proposed for removal, the number actually removed after validation, any validation failures, and the latency of the detection call. Use these logs to tune your [STALENESS_RULES], adjust removal thresholds, and identify patterns where the model is too aggressive or too conservative. If you observe repeated over-removal of a specific category (e.g., user preferences being dropped after a topic shift), add an explicit retention rule to the prompt's [CONSTRAINTS] section rather than trying to fix it through post-hoc validation alone.