Temporal Vagueness Detection and Clarification Prompt

This prompt is designed for RAG operators and search engineers who need to detect when a user query contains temporal constraints that are too vague to translate into reliable retrieval filters. The core job is classification and clarification: given a natural language query, the prompt identifies underspecified time references—such as 'recently,' 'last quarter,' or 'earlier'—and either generates a precise clarification question for the user or proposes a reasonable default date range with explicit assumptions. This is a pre-retrieval guard, not a retrieval step itself. It should sit between the user input and your query rewriting or filter generation logic.

Use this prompt when your retrieval pipeline depends on structured date range filters and you cannot afford silent failures from ambiguous time expressions. It is particularly valuable in domains where temporal precision matters: financial filings, policy documents, operational runbooks, and any corpus where 'last month' could mean a calendar month, a fiscal period, or a rolling 30-day window depending on context. The prompt expects a reference date anchor and, optionally, domain-specific context such as a fiscal calendar definition or the user's timezone. Without these inputs, the model will still flag vagueness but may produce less useful default assumptions.

Do not use this prompt when your retrieval system already handles temporal ambiguity through other means—such as a UI date picker that forces explicit range selection, or a search index that natively scores recency without requiring structured filters. It is also not a replacement for temporal expression extraction or ISO 8601 normalization; those are downstream steps that should consume the clarified output of this prompt. In high-stakes domains like healthcare or legal compliance, always route the proposed default ranges through human review before executing retrieval, because an incorrect assumption about what 'recent' means can silently exclude critical evidence.

This prompt is the core instruction set for a temporal vagueness detection module. It accepts a user query and a reference timestamp, then classifies any time-related constraints as explicit, vague, or missing. For vague references, it must decide whether to ask for clarification or to propose a concrete, bounded date range while stating the assumption it made. The prompt is designed to be placed before a retrieval step in a RAG pipeline, ensuring that downstream vector and keyword searches operate on explicit ISO 8601 intervals rather than ambiguous natural language.

textCopy
You are a temporal constraint analyst for a retrieval system. Your job is to ensure that every time-related constraint in a user query is explicit enough to be converted into a concrete date range for a search index.

## Input
- User Query: [USER_QUERY]
- Reference Timestamp (UTC): [REFERENCE_TIMESTAMP]
- Domain Context: [DOMAIN_CONTEXT]
- Max Clarification Questions: [MAX_CLARIFICATION_QUESTIONS]

## Task
1. Extract all temporal expressions from the User Query.
2. Classify each expression as:
   - `explicit`: Can be converted to an ISO 8601 interval without ambiguity (e.g., "January 2024", "2023-06-01 to 2023-06-30").
   - `vague`: Requires an assumption to resolve (e.g., "recent", "last quarter", "latest").
   - `missing`: The query implies a temporal need but provides no time reference (e.g., "current policy" without a date).
3. For each `vague` or `missing` expression, decide one of two actions:
   - `CLARIFY`: Generate a specific, concise clarifying question.
   - `ASSUME`: Propose a concrete date range in ISO 8601 format and state the assumption explicitly.
   Use the following rules to decide:
   - Prefer `CLARIFY` when the ambiguity materially changes the retrieval result set and the domain is high-stakes (e.g., legal, financial, clinical).
   - Prefer `ASSUME` when a reasonable default exists and the cost of a wrong assumption is low, or when the Domain Context provides a clear default window.
   - Do not exceed [MAX_CLARIFICATION_QUESTIONS] total `CLARIFY` actions. Convert remaining vague expressions to `ASSUME`.
4. If no temporal expressions are found, return an empty list.

## Output Schema
Return a valid JSON object with this structure:
{
  "temporal_expressions": [
    {
      "original_text": "string",
      "classification": "explicit | vague | missing",
      "action": "CLARIFY | ASSUME | NONE",
      "clarifying_question": "string | null",
      "proposed_range": {
        "start": "ISO 8601 date or datetime | null",
        "end": "ISO 8601 date or datetime | null"
      },
      "assumption": "string | null"
    }
  ],
  "total_clarifications": "integer"
}

## Constraints
- All dates must be in ISO 8601 format.
- Use the Reference Timestamp as the anchor for all relative expressions.
- If the Domain Context specifies a fiscal calendar, use it for quarter and year references.
- Never invent dates that are not derivable from the query, reference timestamp, or domain context.
- If a query contains contradictory temporal constraints, flag the conflict and do not propose a range.

To adapt this prompt, replace the square-bracket placeholders with values from your application context. [USER_QUERY] is the raw input string. [REFERENCE_TIMESTAMP] should be the current UTC time in ISO 8601 format, injected by your application at runtime. [DOMAIN_CONTEXT] can be a short string like "financial filings, fiscal year ends Jan 31" or "news articles, recency window 7 days"—this guides the assumption logic. [MAX_CLARIFICATION_QUESTIONS] is an integer (typically 1 or 2) that prevents the system from asking too many questions in a single turn. After the prompt returns, validate the JSON output against the schema before passing the resolved date ranges to your retrieval engine. If the output contains CLARIFY actions, surface those questions to the user and re-run the prompt with the clarified query.

This prompt sits as a pre-retrieval guard in your query pipeline. Before any vector or keyword search executes, route the user's raw query through this prompt to classify whether temporal constraints are sufficiently concrete. The model should return a structured JSON decision: either status: 'clear' with extracted ISO 8601 ranges, or status: 'vague' with a clarifying question and a set of proposed default ranges plus explicit assumptions. Your application code then branches: clear queries proceed to retrieval with the extracted ranges injected as metadata filters; vague queries either surface the clarifying question to the user (interactive mode) or log the assumption and proceed with the default range (automated mode).

Integration pattern: Wrap the prompt call in a lightweight service function with the following contract. Input: the raw user query string and a reference_timestamp (typically now() in the user's timezone). Output: a typed object with status, clarifying_question, assumed_range (ISO 8601 start/end), confidence (0-1), and assumptions (array of strings). Validate the output with a JSON schema validator before branching. If the model returns malformed JSON or missing required fields, retry once with a stricter system instruction that includes the schema inline. After two failures, log the raw response, set status: 'vague', and fall back to a conservative default range (e.g., last 90 days) with the assumption explicitly recorded.

Model choice and latency: This is a classification-plus-extraction task with moderate reasoning requirements. A fast model like Claude Haiku, GPT-4o-mini, or Gemini Flash is usually sufficient and keeps pre-retrieval latency under 500ms. If you observe over-eagerness to classify queries as clear (false negatives on vagueness), add a few-shot example in the prompt showing a query like 'recent reports' being correctly flagged as vague. Logging and observability: Log every decision with query_id, status, confidence, assumed_range, and the full prompt response. This log becomes your audit trail for why a particular date filter was applied. In high-stakes domains (financial reporting, legal discovery, clinical guidelines), require a human reviewer to approve any automated assumption where confidence < 0.8 before retrieval executes.

Eval integration: Before deploying, build a test harness with 50-100 labeled queries covering clear temporal references ('January 2024', 'Q3 2023'), vague references ('lately', 'current', 'modern'), and edge cases ('this quarter' on January 1st). Measure precision and recall on vagueness detection, and separately measure the accuracy of extracted date ranges for clear queries. Set a release gate: precision on vagueness detection must exceed 0.90, and date range accuracy must exceed 0.95. Run this eval suite on every prompt version change. What to avoid: Do not use this prompt to resolve vagueness silently without logging the assumption. Do not skip the JSON schema validation step—malformed date strings will break your downstream metadata filter construction. Do not apply this prompt to queries that already contain explicit date filters from a UI date picker; those should bypass this step entirely.