Temporal Relevance Justification Prompt

Use this prompt when your system needs to explain its temporal reasoning to users, auditors, or downstream systems. It takes a query, a piece of evidence with a publication date, and a temporal relevance classification, then produces a structured justification statement. This is essential for compliance engineers building audit trails, user-facing AI designers who need to show their work, and any team where evidence freshness decisions must be transparent and contestable.

This prompt is a post-hoc explanation generator, not a decision-maker. It assumes you have already classified the evidence as temporally relevant or irrelevant using an upstream component such as a Temporal Relevance Scoring Prompt or Stale Evidence Detection Prompt. The justification it produces should be treated as a draft that requires validation against the original evidence metadata. In regulated or high-risk domains, always route the output through a human review step before it appears in an audit log or user interface. The prompt works best when the input includes a clear relevance classification label, a publication date in ISO 8601 format, and the original user query for context.

Do not use this prompt to make the relevance decision itself. It will fabricate plausible-sounding justifications even when the underlying classification is wrong, which creates a false sense of rigor. Pair it with a calibrated scoring prompt upstream and an evaluation rubric downstream. For production systems, log every justification alongside its inputs and the model version used, so that contested explanations can be traced back to their source. If you need to justify why evidence was excluded from a ranked list, use this prompt once per excluded passage rather than attempting to batch multiple justifications in a single call.

This template produces structured temporal relevance justifications suitable for audit trails, user-facing explanations, and compliance review. Replace each square-bracket placeholder with your actual data before sending the prompt to the model. The template is designed to work with any retrieved evidence set and query pair, producing explanations that cite specific dates, time windows, and relevance criteria rather than vague statements about recency.

textCopy
You are an evidence transparency analyst. Your task is to explain why specific evidence passages were considered temporally relevant or irrelevant to a given query. Produce justifications that are clear enough for audit review and end-user understanding.

## INPUT
Query: [QUERY]
Query Date: [QUERY_DATE]
Temporal Sensitivity Classification: [TEMPORAL_SENSITIVITY]
Required Time Window (if any): [REQUIRED_TIME_WINDOW]

Evidence Passages:
[EVIDENCE_PASSAGES]

Each evidence passage includes:
- passage_id: unique identifier
- content: the passage text
- publication_date: ISO 8601 date when the source was published
- last_updated_date: ISO 8601 date when the source was last updated (if available)
- source_authority_score: 0-1 score indicating source trustworthiness
- relevance_score: 0-1 score indicating semantic relevance to the query

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "justifications": [
    {
      "passage_id": "string",
      "temporal_relevance_decision": "RELEVANT" | "IRRELEVANT" | "UNCERTAIN",
      "justification_statement": "string explaining the decision in plain language, citing specific dates and the reasoning",
      "temporal_factors": {
        "age_at_query_time": "string describing how old the evidence was at query time",
        "within_required_window": true | false | null,
        "freshness_concern": "string describing any staleness risk, or null if none",
        "domain_decay_assessment": "string describing whether the domain's rate of change makes this evidence stale, or null if not applicable"
      },
      "confidence": 0.0-1.0
    }
  ],
  "summary": "string providing an overall temporal relevance assessment for the evidence set"
}

## CONSTRAINTS
- Every justification_statement must reference specific dates from the evidence and query.
- Do not fabricate dates. If a date is missing, state that explicitly.
- When temporal_relevance_decision is UNCERTAIN, explain what information would resolve the uncertainty.
- For evidence classified as IRRELEVANT due to staleness, suggest what time range would be acceptable.
- Confidence scores must reflect genuine uncertainty: use 0.5-0.7 for borderline cases, not just 0.0 or 1.0.
- If the query is time-agnostic, explain why temporal factors were deprioritized rather than ignored.

## EXAMPLES
Query: "What were Tesla's Q3 2024 earnings?"
Query Date: 2024-11-15
Temporal Sensitivity: recent
Required Time Window: 2024-09-01 to 2024-11-15

Evidence Passage:
{
  "passage_id": "p1",
  "content": "Tesla reported Q3 2024 revenue of $25.18 billion...",
  "publication_date": "2024-10-23",
  "last_updated_date": null,
  "source_authority_score": 0.9,
  "relevance_score": 0.95
}

Expected justification:
{
  "passage_id": "p1",
  "temporal_relevance_decision": "RELEVANT",
  "justification_statement": "This passage was published on 2024-10-23, which falls within the required time window of 2024-09-01 to 2024-11-15 for Q3 2024 earnings data. At query time (2024-11-15), the evidence was 23 days old, well within acceptable freshness for quarterly financial reporting.",
  "temporal_factors": {
    "age_at_query_time": "23 days",
    "within_required_window": true,
    "freshness_concern": null,
    "domain_decay_assessment": "Financial earnings data typically remains current until the next quarterly report. This evidence is from the most recent quarter."
  },
  "confidence": 0.95
}

## RISK_LEVEL
[HIGH if justifications will be used in regulated contexts requiring auditability; MEDIUM if used for user-facing explanations in non-regulated products; LOW if used for internal debugging only]

Adapt this template by adjusting the output schema fields to match your audit requirements. If your system already has a temporal scoring model, add a temporal_score field and require the justification to reconcile any discrepancy between the score and the explanation. For high-risk domains, add a reviewer_notes field and route UNCERTAIN decisions to human review before they reach end users. Test the template against a golden dataset of 20-50 query-evidence pairs with known temporal relationships to calibrate confidence thresholds before production deployment.

The Temporal Relevance Justification Prompt is designed to be called after evidence retrieval and temporal scoring but before the final answer generation step. In a typical RAG pipeline, you will have already retrieved a set of candidate passages and run a temporal relevance scoring prompt against each one. This justification prompt takes the scored passages and the original query as input, producing human-readable explanations that can be stored in an audit trail, displayed to users who click 'Why this source?', or fed into downstream explainability dashboards. The prompt is not a real-time critical-path component for answer generation—it is an explainability sidecar that runs in parallel or on demand.

Wire this prompt as an asynchronous post-processing step. After your main RAG pipeline selects and ranks evidence, send the top-N passages with their temporal scores to this justification prompt. Store the output alongside the final answer in your audit log, keyed by request_id. For user-facing applications, lazy-load the justifications when a user expands a citation or clicks an info icon. This avoids adding latency to the primary response path. Use a structured output schema with fields for passage_id, temporal_relevance_justification, key_date_factors, and confidence. Validate the output against this schema before storage—reject any response where passage_id doesn't match an input passage or where the justification is empty. On validation failure, retry once with a stricter prompt variant that includes the validation error message. If the retry also fails, log the failure and fall back to a generic temporal note derived from the passage metadata rather than blocking the user experience.

For high-stakes domains like financial intelligence or healthcare, route justification outputs through a human review queue when the temporal relevance score falls in an ambiguous range (e.g., 0.4–0.7) or when the justification contains uncertainty markers like 'may be outdated' or 'unclear publication date.' Implement a review UI that shows the original query, the passage, the temporal score, and the generated justification side by side, with approve/edit/reject actions. Approved justifications can be fed back as few-shot examples in future prompt calls to improve consistency. Avoid calling this prompt on every passage in a large retrieval set—limit to the top 5–10 passages that actually influence the final answer. For model selection, a fast mid-tier model like GPT-4o-mini or Claude Haiku is usually sufficient for justification generation, reserving larger models for the primary answer synthesis step.