Upcoming and Next Temporal Intent Disambiguation Prompt

This prompt is designed for calendar, scheduling, and event-driven RAG systems where a user query contains a forward-looking temporal reference like 'next Friday,' 'upcoming earnings,' or 'the next team standup.' The core job is intent disambiguation: does the user mean the single chronologically immediate instance of that event, or are they referring to a broader future period? A naive date parser will fail here because the correct answer depends on context, the current date, and the nature of the event itself. The ideal user is a RAG developer or search engineer building a retrieval pipeline over a time-sensitive corpus (meetings, earnings calls, release schedules, maintenance windows) where resolving this intent correctly is the difference between retrieving the right document and retrieving a stale or irrelevant one.

You should use this prompt when your system must convert an ambiguous 'upcoming' or 'next' reference into a concrete, machine-readable date range or a set of candidate ranges with confidence scores. The prompt requires a reference date (usually the current date or the user's 'today'), the user's raw query, and optionally a known event catalog or schedule context. It is not a general-purpose date parser. Do not use this prompt for historical queries ('last Friday'), for queries with explicit absolute dates ('on March 3rd'), or for simple relative date normalization that doesn't involve event anchoring. Those tasks are better served by the Relative Date Normalization or Temporal Expression to ISO 8601 Conversion prompts in this pillar.

The primary failure mode this prompt addresses is the 'Friday Problem': if today is Wednesday the 10th, does 'next Friday' mean the 12th (the immediate upcoming Friday) or the 19th (the Friday of next week)? The answer varies by dialect, region, and even corporate culture. This prompt forces the model to reason aloud about the ambiguity, anchor its decision to a stated convention or event context, and output a structured result that your application can validate. Before deploying, you must test this prompt against a golden dataset of queries with known intent labels for your specific domain and locale. If the output will drive a high-stakes action like a missed meeting or a financial trade, always route low-confidence disambiguations to a human for confirmation rather than silently defaulting to one interpretation.

This prompt template resolves the ambiguity inherent in phrases like 'next Friday', 'upcoming earnings', or 'the next meeting'. The core challenge is that 'next' can mean the immediately upcoming instance or the instance in the following calendar period, and 'upcoming' can refer to a single event or a forward-looking window. The prompt forces the model to classify the user's likely intent and produce a concrete date range, making it suitable for calendar, scheduling, and event-driven RAG systems where retrieval requires explicit boundaries.

Below is the copy-ready prompt template. All square-bracket placeholders must be replaced by your application before sending the request. The [REFERENCE_DATE] anchors all relative time calculations. [EVENT_CATALOG] provides known event definitions when the query references named events like 'earnings' or 'product launch'. [OUTPUT_SCHEMA] enforces a structured response your parser can consume. [WEEK_START] disambiguates week boundaries across locales.

textCopy
You are a temporal intent disambiguation engine. Your job is to resolve ambiguous 'upcoming' and 'next' references into explicit date ranges.

## Input
- User Query: [USER_QUERY]
- Reference Date (today): [REFERENCE_DATE]
- Week Start Day: [WEEK_START]
- Known Events: [EVENT_CATALOG]

## Task
1. Identify all temporal expressions in the query that use 'upcoming', 'next', or similar forward-looking language.
2. For each expression, classify the user's intent as one of:
   - `immediate_next`: The single soonest occurrence after the reference date.
   - `calendar_next`: The occurrence in the next calendar period (next week, next month, next quarter).
   - `upcoming_window`: A forward-looking range containing multiple possible occurrences.
   - `named_event`: A reference to a known event from the catalog.
3. Resolve each expression to an explicit date range with start and end dates in ISO 8601 format (YYYY-MM-DD).
4. If the intent is ambiguous, provide the most likely resolution and flag the ambiguity.

## Constraints
- Always use the reference date as the anchor. Do not use the current system date.
- For 'next [weekday]': if today is that weekday, 'next' means the weekday in the next calendar week unless the query says 'today' or 'this [weekday]'.
- For 'upcoming [event]': check the event catalog first. If not found, treat as a 30-day forward window from the reference date.
- If the query contains no temporal expression, return an empty resolutions array.
- Never invent event dates not present in the catalog.

## Output Schema
Return valid JSON matching this structure:
[OUTPUT_SCHEMA]

## Examples
[EXAMPLES]

Adaptation guidance: Replace [USER_QUERY] with the raw user input. Set [REFERENCE_DATE] to the conversation's temporal anchor—typically the current date in the user's timezone, not UTC now. Populate [EVENT_CATALOG] with a JSON array of known events, each containing a name, date, and optional recurrence rule. Define [OUTPUT_SCHEMA] as a JSON Schema object that includes fields for resolutions (array of objects with expression, intent_class, start_date, end_date, confidence, and ambiguity_flag). Provide [EXAMPLES] as 2-3 few-shot demonstrations covering the most common disambiguation cases in your domain. If your application handles high-stakes scheduling (medical appointments, legal deadlines, financial transactions), add a [RISK_LEVEL] parameter and require explicit human confirmation when confidence falls below a threshold. Test this prompt against edge cases: Monday referencing 'next Friday', month-boundary rollover, leap years, and queries containing both 'this' and 'next' for the same entity type.

The Upcoming and Next Temporal Intent Disambiguation Prompt is designed to sit between the user's natural language query and the retrieval or calendar API call. Its job is to resolve ambiguous references like 'next Friday' or 'upcoming earnings' into a concrete classification (IMMEDIATE_NEXT or FUTURE_PERIOD) and a corresponding date range. This classification must happen before any downstream search or scheduling action, because the wrong interpretation silently produces results that look correct but are temporally wrong. The prompt should be called as a dedicated pre-retrieval step, not folded into a larger answer-generation prompt where temporal reasoning can be diluted by other instructions.

Wire the prompt into your application as a synchronous pre-processing function. Accept the user query string and a reference datetime (typically now() in the user's timezone) as inputs. The prompt returns a structured JSON object with intent_class, date_range_start, date_range_end, and confidence. Before passing this output to your retrieval system, validate it: confirm that date_range_start is before date_range_end, that the range is not in the past for IMMEDIATE_NEXT classifications (unless the reference time is very close to the boundary), and that confidence meets your minimum threshold (start with 0.7 and tune based on eval results). If validation fails, log the failure with the original query, the raw model output, and the validation error, then either fall back to a safe default range or surface a clarification question to the user. For high-stakes scheduling applications, add a human review step when confidence is below 0.85 or when the classification flips between IMMEDIATE_NEXT and FUTURE_PERIOD on retry.

Choose a model with strong instruction-following and JSON output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 2.0 Flash all perform well on this structured classification task. Set temperature=0 to minimize variance in boundary decisions. Implement a single retry with exponential backoff if the output fails JSON schema validation or if the model returns a confidence below your threshold on the first attempt. Log every invocation with the query, reference datetime, model response, validation result, and final date range for debugging weekday-boundary and event-anchoring edge cases. Avoid calling this prompt inside a loop or agentic planner without caching results for identical query-reference pairs, as temporal resolution is deterministic given the same inputs and repeated calls waste tokens.