Stale Context Identification and Removal Prompt

This prompt is designed for long-running AI sessions, knowledge bases, or agent workflows where some context items have become outdated. Its primary job is to assess each context item for staleness based on provided timestamps, version markers, and contradictions with fresher evidence. The ideal user is an AI engineer or operator managing a system where context accumulates over time—such as a multi-turn copilot, a RAG pipeline ingesting versioned documents, or an agent with a persistent memory store—and where stale information is actively degrading answer quality, increasing token costs, or causing the model to contradict newer, more reliable data.

Use this prompt when context staleness is a measurable problem: when session length exceeds practical token limits and older turns contain resolved or superseded information, when a knowledge base has been updated and older entries now conflict with current facts, or when an agent's memory contains decisions based on data that has since changed. It is particularly effective when each context item carries temporal or version metadata (e.g., ingested_at, version, last_verified) that the prompt can use to make staleness determinations. The output is a pruned context set with explicit staleness justifications, ready for downstream tasks like answer generation or further compression. Do not use this prompt for real-time safety-critical decisions without human review, or when context items lack any temporal or version metadata, as the staleness assessment will be unreliable. It is also not a substitute for a full factuality check; it identifies staleness, not hallucination.

Before integrating this prompt into a production pipeline, ensure you have a clear definition of what 'stale' means for your domain. For a news summarization system, a context item might be stale after 24 hours; for a legal research tool, a statute might be stale only when a new version is published. Wire the prompt into a pre-inference step that runs before the main generation call, and always log the staleness justifications for auditability. If the prompt recommends dropping a context item that a downstream task might still need, consider a human-in-the-loop review step or a conservative retention policy for high-risk domains.

The following prompt template is designed to be copied directly into your AI harness. It accepts a list of context items, each with associated metadata such as timestamps, version markers, and source identifiers. The model's job is to assess each item for staleness based on the provided criteria, produce a structured staleness assessment, and return a pruned context set with justifications for every removal. Replace every square-bracket placeholder with your actual data before sending this to the model. The template is self-contained: it includes the role, task definition, output schema, constraints, and evaluation criteria needed for a reliable run.

textCopy
You are a context quality auditor. Your task is to review a set of context items from a long-running session or knowledge base and identify which items have become stale. Staleness means the information is outdated, superseded by fresher evidence, contradicted by a more recent source, or no longer relevant to the current task state.

## INPUT
You will receive a JSON array of context items. Each item has:
- `id`: string, unique identifier
- `content`: string, the context text
- `timestamp`: ISO 8601 string, when the item was created or last updated
- `version`: string or null, version marker if available
- `source`: string, origin of the context (e.g., "user_message", "tool_output", "retrieved_document", "system_note")
- `tags`: array of strings, optional category labels

Context items:
[CONTEXT_ITEMS]

## CURRENT STATE
- Current task: [CURRENT_TASK_DESCRIPTION]
- Current time: [CURRENT_TIMESTAMP]
- Fresh evidence available (if any): [FRESH_EVIDENCE_SUMMARY]

## STALENESS CRITERIA
Evaluate each context item against these criteria. An item is stale if ANY of the following apply:
1. **Temporal staleness**: The item's timestamp is older than [MAX_AGE_THRESHOLD] and the content describes time-sensitive information (e.g., statuses, availability, prices, schedules).
2. **Version staleness**: The item's version marker is lower than a known current version [CURRENT_VERSION] for that data category.
3. **Contradiction staleness**: The item's content directly contradicts information in the fresh evidence provided above. Flag the contradiction explicitly.
4. **Relevance staleness**: The item's content is no longer relevant to the current task described above. This applies to resolved questions, completed actions, or context from a different workflow stage.
5. **Supersession staleness**: A fresher context item in the same input set covers the same information more completely or accurately. When this occurs, mark the older item as stale and reference the superseding item's ID.

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "staleness_assessments": [
    {
      "item_id": "string",
      "is_stale": boolean,
      "staleness_reasons": ["string"],  // list of applicable criteria from above: "temporal", "version", "contradiction", "relevance", "supersession"
      "contradiction_detail": "string or null",  // required if contradiction staleness applies; quote the conflicting fresh evidence
      "superseded_by": "string or null",  // required if supersession staleness applies; ID of the fresher item
      "confidence": "high" | "medium" | "low"
    }
  ],
  "pruned_context": [
    // array of context items (full objects) that are NOT stale and should be retained
  ],
  "removal_summary": {
    "total_items": number,
    "stale_items": number,
    "retained_items": number,
    "high_confidence_removals": number,
    "low_confidence_removals": number
  }
}

## CONSTRAINTS
- Do NOT modify the content of retained items. Return them exactly as provided.
- If confidence is "low" for any staleness decision, include a note in `staleness_reasons` explaining the uncertainty.
- If fresh evidence contradicts an item, you MUST quote the specific conflicting passage in `contradiction_detail`.
- Never mark an item as stale solely because it is old if the content is clearly time-invariant (e.g., definitions, static facts, policies without expiration).
- If two items are near-duplicates with similar timestamps, retain the one with higher information density or more authoritative source. Justify in `staleness_reasons`.

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high", apply stricter retention: only remove items with "high" confidence staleness. Flag "medium" confidence items for human review instead of removing them.

## EXAMPLES
[EXAMPLES]

Return ONLY the JSON object. No markdown fences, no commentary.

To adapt this template for your system, start by mapping your context store's schema to the CONTEXT_ITEMS array format. The timestamp field is critical for temporal staleness checks, so ensure it is populated and in a consistent ISO 8601 format. The FRESH_EVIDENCE_SUMMARY placeholder should contain the most recent information available to the system—this could be the latest tool output, a user correction from the current turn, or a newly retrieved document. If no fresh evidence exists, set this field to "None" and the model will skip contradiction checks. The RISK_LEVEL parameter gates removal aggressiveness: use "high" for compliance, healthcare, or legal contexts where dropping evidence carries audit risk, and "low" for chat history cleanup where occasional over-removal is acceptable. The EXAMPLES placeholder should contain one or two few-shot demonstrations showing correct staleness assessments, especially for edge cases like time-invariant definitions or near-duplicate handling. Test the prompt with a golden dataset of context items where you know the correct staleness labels before deploying to production.

After copying the template, validate the assembled prompt before inference. Check that all placeholders are replaced, the CONTEXT_ITEMS array is valid JSON, and the total token count fits within your model's context window. For high-risk deployments, add a post-processing step that compares the low_confidence_removals count against a threshold and escalates to human review if it exceeds your tolerance. Log the full staleness assessment alongside the pruned context so you can audit removal decisions later. Do not use this prompt for real-time safety-critical context pruning without a human-in-the-loop fallback for any item flagged with "low" confidence.

This prompt is designed to be called as a preprocessing step before context is packed into a downstream task prompt. In a typical RAG or long-running agent architecture, you'll invoke this prompt when a session exceeds a configurable turn count, when a knowledge base update event fires, or when a scheduled staleness sweep runs. The prompt expects a list of context items, each with an id, content, timestamp, and optional version or source fields. The application layer is responsible for assembling this structured input from your context store before calling the model.

Wire the prompt into your pipeline as an async preflight step. Construct the input payload by querying your context store for all active items in the current session or retrieval set, then serialize them into the [CONTEXT_ITEMS] placeholder as a JSON array. Set [CURRENT_TIMESTAMP] to the ISO 8601 timestamp of the request. For the [STALENESS_THRESHOLD] placeholder, use a configurable duration string such as '7 days' or '30 days' that your operations team can tune. After receiving the model response, validate the output against the [OUTPUT_SCHEMA] you provided in the prompt: each item in the pruned_context array must have a valid id that maps back to an input item, a retention_decision of keep or remove, and a non-empty staleness_justification string. Reject and retry any response that fails schema validation, contains orphaned IDs, or drops more than a configured percentage of items without explicit justifications.

Implement a retry wrapper with exponential backoff (starting at 1 second, max 3 attempts) for schema validation failures and model API errors. Log every invocation with a trace ID, the count of input items, the count of retained items, and the staleness decisions as structured metadata—this is critical for debugging downstream quality issues that may trace back to over-aggressive pruning. For high-stakes domains such as healthcare, legal, or finance, route any context item flagged for removal with a risk_level of high to a human review queue before the item is actually dropped from the context window. The review queue should present the original item, the model's staleness justification, and a one-click approve/override action. Never silently drop context in regulated workflows; the prompt's output is a recommendation, not a final action.

Choose a model with strong structured output adherence for this task—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are good defaults. Avoid small or instruction-light models that may conflate staleness with irrelevance or produce inconsistent JSON. If you're running this prompt at high volume (e.g., sweeping thousands of sessions nightly), consider batching multiple context sets into a single request with clear delimiters, or use a cheaper model for the initial classification pass and escalate ambiguous cases to a stronger model. Cache the staleness assessment results with a TTL tied to the next expected knowledge base update, so you don't re-evaluate unchanged context on every turn.

The most common production failure mode is the model removing context that is factually old but still procedurally relevant—such as a policy document from two years ago that remains in effect. Mitigate this by including explicit [CONSTRAINTS] in your prompt that forbid removal of items tagged with immutable: true or policy_document type markers. Monitor the ratio of removed-to-retained items over time; a sudden spike in removals often indicates a knowledge base refresh that the model is over-reacting to. Wire an alert on this metric and be prepared to temporarily disable automated pruning while you investigate.