Temporal Inconsistency Detection Prompt

This prompt is designed for multi-turn assistant and copilot systems that reference events, dates, or sequences across conversation turns. Its job is to detect when the assistant's internal understanding of temporal order or event recency contradicts the user's most recent statements. Use this prompt before generating a response that depends on event sequencing, deadlines, or historical facts. It is not a general staleness detector; it specifically targets subtle temporal contradictions that naive date comparison would miss, such as a user correcting the order of two past events without providing explicit timestamps.

The ideal user is an AI engineer or product developer building a copilot for scheduling, project management, case tracking, or any domain where the sequence of events is critical. The required context includes the assistant's current temporal model (a structured or unstructured understanding of event order) and the user's latest turn. The prompt is most valuable when the user's correction is implicit—for example, saying 'No, the design review happened before the budget meeting' without providing new dates. A simple date parser would see no conflict, but this prompt identifies that the assistant's prior sequence is now invalid.

Do not use this prompt for detecting stale retrieved documents, general knowledge cut-off issues, or factual inaccuracies that are not about temporal order. It is also not a replacement for explicit slot-tracking in a dialogue state manager. If your system already maintains a strict temporal graph with formal timestamps, use a deterministic comparator instead. This prompt is for the gray area where language implies a sequence change without explicit data. In high-stakes domains like legal case management or medical scheduling, always route flagged inconsistencies to a human reviewer before acting on the corrected timeline.

This prompt template is designed to be dropped into a multi-turn assistant pipeline immediately after a new user turn is received. It compares the user's latest message against a structured representation of the conversation's event timeline, identifying contradictions in ordering, recency, or event existence that naive date parsing would miss. The output is a machine-readable inconsistency report that your application can use to trigger a context refresh, ask a clarification question, or flag the response for human review.

textCopy
You are a temporal consistency auditor for a multi-turn assistant. Your job is to detect when the assistant's understanding of event order, timing, or recency contradicts the user's latest statement.

## INPUTS

### Conversation Event Timeline
A structured list of events the assistant believes to be true, in chronological order. Each event has an ID, description, and optional timestamp.

[TIMELINE]

### User's Latest Message
[USER_MESSAGE]

### Assistant's Planned Response (optional)
[PLANNED_RESPONSE]

## TASK
Compare the user's latest message against the event timeline. Identify any temporal contradictions where:
1. The user implies an event order that conflicts with the timeline.
2. The user references an event as recent that the timeline places in the past (or vice versa).
3. The user denies, corrects, or updates an event that exists in the timeline.
4. The user introduces a new event that cannot logically fit within the existing timeline sequence.
5. The assistant's planned response relies on a temporal assumption the user has just invalidated.

Do NOT flag:
- Events the user simply hasn't mentioned yet.
- Minor phrasing differences that don't change temporal meaning.
- User statements about future plans unless they contradict established past events.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:

{
  "temporal_inconsistencies_detected": boolean,
  "inconsistencies": [
    {
      "conflict_type": "order_reversal" | "recency_mismatch" | "event_denial" | "impossible_insertion" | "assumption_invalidated",
      "timeline_event_id": "string or null",
      "timeline_event_description": "string",
      "user_statement_excerpt": "string",
      "contradiction_explanation": "string",
      "suggested_correction": "string",
      "confidence": 0.0-1.0
    }
  ],
  "timeline_needs_rebuild": boolean,
  "recommended_action": "refresh_timeline" | "ask_clarification" | "flag_for_review" | "none"
}

## CONSTRAINTS
- Only flag contradictions where the temporal meaning is clear, not ambiguous.
- Set confidence below 0.7 if the contradiction could be explained by the user speaking informally.
- If multiple contradictions exist, list all of them.
- If the timeline is empty or the user message contains no temporal content, return inconsistencies_detected: false with an empty array.
- Do not hallucinate events. Only reference events that exist in the provided timeline.

## EXAMPLES

### Example 1: Order Reversal
Timeline:
- ID: ev1 | Description: User submitted the expense report | Timestamp: 2024-03-10
- ID: ev2 | Description: Manager approved the expense report | Timestamp: 2024-03-12

User Message: "Actually, my manager approved it before I submitted it. I had pre-approval."

Output:
{
  "temporal_inconsistencies_detected": true,
  "inconsistencies": [
    {
      "conflict_type": "order_reversal",
      "timeline_event_id": "ev1",
      "timeline_event_description": "User submitted the expense report on 2024-03-10",
      "user_statement_excerpt": "my manager approved it before I submitted it",
      "contradiction_explanation": "Timeline has submission before approval. User states approval occurred first as pre-approval.",
      "suggested_correction": "Reorder events: approval (pre-approval) occurred before submission, or add a pre-approval event before submission.",
      "confidence": 0.95
    }
  ],
  "timeline_needs_rebuild": true,
  "recommended_action": "refresh_timeline"
}

### Example 2: No Contradiction
Timeline:
- ID: ev1 | Description: Team discussed Q3 roadmap | Timestamp: 2024-07-05

User Message: "Can you remind me what we decided about the Q4 budget?"

Output:
{
  "temporal_inconsistencies_detected": false,
  "inconsistencies": [],
  "timeline_needs_rebuild": false,
  "recommended_action": "none"
}

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high", you MUST include explicit reasoning for each inconsistency and set a lower confidence threshold for flagging. If RISK_LEVEL is "low", you may skip low-confidence contradictions below 0.6.

To adapt this template for your application, replace the square-bracket placeholders at runtime. [TIMELINE] should be populated from your dialogue state manager with the current event sequence the assistant believes to be true. [USER_MESSAGE] is the raw latest user turn. [PLANNED_RESPONSE] is optional but valuable—include it when your assistant has already drafted a response, so the prompt can catch temporal assumptions baked into that draft before it reaches the user. Set [RISK_LEVEL] based on your domain: use "high" for healthcare, finance, or legal workflows where temporal errors cause real harm, and "low" for casual chat where a missed contradiction is an annoyance rather than a liability. After receiving the JSON output, your application should branch: if temporal_inconsistencies_detected is true, suppress the planned response, execute the recommended_action, and log the inconsistency for eval review. If false, proceed with the planned response. Always log the full output for trace analysis, especially the confidence scores, so you can tune your detection threshold over time.

The Temporal Inconsistency Detection Prompt is designed to operate as a stateful guard within a conversation pipeline, not as a standalone chat. It should be invoked after every user turn that references a time, date, sequence, or event, comparing the assistant's current understanding of the timeline against the user's latest statement. The prompt expects three structured inputs: the assistant's current temporal state model, the latest user turn, and the full conversation history for context. The output is a structured JSON object containing flagged inconsistencies, conflicting statements, and a suggested correction. This output should be parsed by the application layer to update the assistant's internal state before generating the next response.

To integrate this into a production system, wrap the prompt call in a validation and retry loop. First, validate that the output JSON conforms to the expected schema: a top-level inconsistencies array where each object contains conflicting_statements (an array of two or more strings), detected_contradiction (a string), and suggested_correction (a string or null). If the model returns malformed JSON or a schema mismatch, retry once with a stricter instruction appended to the original prompt, such as 'Respond ONLY with valid JSON matching the specified schema.' If the retry also fails, log the raw output and escalate for human review rather than silently proceeding with potentially corrupted state. For high-stakes domains like healthcare scheduling or financial transaction timelines, always route flagged inconsistencies to a human review queue before applying any state correction.

Model choice matters here. This task requires strong instruction-following and structured output capabilities. Prefer models with native JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) and set response_format to json_object where the API supports it. For open-weight models, use a grammar-constrained sampler like llama.cpp's GBNF grammar to enforce the output schema. Log every invocation—including the input state, the raw model output, the parsed result, and whether a correction was applied—to a structured logging system. This audit trail is essential for debugging false positives (flagging a non-contradiction) and false negatives (missing a real temporal inconsistency). Finally, avoid running this prompt on every turn unconditionally; use a lightweight classifier or keyword filter to skip turns with no temporal references, saving latency and cost.