Since and Until Boundary Extraction Prompt

This prompt is designed for retrieval pipeline builders who need to parse explicit temporal boundary markers from user queries—phrases like 'since January', 'until last month', or 'from 2020 onward'. The job-to-be-done is converting natural language boundary expressions into structured start and end constraints with clear operator semantics (inclusive, exclusive, open-ended) that can be directly translated into metadata filter clauses for vector databases, search indexes, or SQL WHERE conditions. The ideal user is a RAG developer or search engineer who already has a retrieval system that supports date-range filtering and needs reliable extraction of boundary intent from user queries.

Use this prompt when your retrieval system requires explicit start and end boundaries rather than relative date ranges. It is specifically designed for queries that contain boundary markers like 'since', 'until', 'from', 'after', 'before', 'up to', or 'onward'. The prompt produces structured output with start and end objects, each containing a date value, an operator (gte, gt, lte, lt, or null for open boundaries), and a confidence flag. This is distinct from relative date normalization prompts that convert 'last quarter' into ISO ranges—this prompt assumes the user has already provided explicit boundary language and needs operator disambiguation. For example, 'since January 2024' should produce a start boundary with gte (inclusive) while 'after January 2024' should produce gt (exclusive).

Do not use this prompt for queries that express relative time periods without boundary markers ('last 30 days', 'recent', 'this quarter'). Those queries should be routed to relative date normalization or temporal vagueness detection prompts instead. Also avoid this prompt when the retrieval system does not support boundary operators and only accepts concrete date ranges—in that case, pair this prompt with a downstream resolution step that converts operator semantics into explicit dates. For high-stakes applications like legal document retrieval or financial compliance, always add a validation layer that checks extracted boundaries against the source query and logs any ambiguous cases for human review. The prompt works best as part of a pre-retrieval pipeline stage, positioned after query disambiguation and before metadata filter construction.

This prompt template is designed to be dropped directly into a retrieval pipeline preprocessing step. It takes a raw user query containing boundary markers such as 'since', 'until', 'from', 'after', 'before', or 'between' and extracts the intended start and end points along with the correct comparison operators (gte, lte, gt, lt). The output is a structured JSON object ready to be consumed by a metadata filter builder, not a natural language explanation. The template uses square-bracket placeholders so you can inject the user query, a reference date, and any domain-specific constraints without modifying the core instruction.

textCopy
You are a temporal boundary extraction system. Your job is to parse explicit boundary markers from a user query and return structured start and end constraints with operator semantics.

INPUT:
- User Query: [USER_QUERY]
- Reference Date (ISO 8601): [REFERENCE_DATE]
- Timezone: [TIMEZONE]

OUTPUT_SCHEMA:
Return a valid JSON object with this exact structure:
{
  "start": {
    "value": "ISO 8601 date string or null",
    "operator": "gte | gt | null",
    "original_text": "the exact phrase from the query that produced this boundary or null"
  },
  "end": {
    "value": "ISO 8601 date string or null",
    "operator": "lte | lt | null",
    "original_text": "the exact phrase from the query that produced this boundary or null"
  },
  "is_open_ended": true or false,
  "boundary_type": "explicit_start_only | explicit_end_only | explicit_range | implicit | none",
  "confidence": 0.0 to 1.0
}

CONSTRAINTS:
- Only extract boundaries that are explicitly stated in the query. Do not infer or assume ranges.
- If the query says 'since January 2024', the start operator is 'gte' and the end is null.
- If the query says 'until last month', the end operator is 'lte' and the start is null.
- If the query says 'from March to June 2024', the start operator is 'gte' and the end operator is 'lte'.
- If the query says 'after Q2 2023', the start operator is 'gt'.
- If the query says 'before 2020', the end operator is 'lt'.
- Resolve all relative expressions using the provided reference date and timezone.
- If no boundary markers are present, set both start and end values to null, is_open_ended to true, boundary_type to 'none', and confidence to 1.0.
- If a boundary is mentioned but cannot be resolved to a date, set its value to null, keep the original_text, and set confidence below 0.5.
- Return only the JSON object. No markdown, no explanation.

EXAMPLES:

Query: 'revenue reports since January 2024'
Reference Date: 2025-01-15
Timezone: America/New_York
Output:
{
  "start": {
    "value": "2024-01-01",
    "operator": "gte",
    "original_text": "since January 2024"
  },
  "end": {
    "value": null,
    "operator": null,
    "original_text": null
  },
  "is_open_ended": true,
  "boundary_type": "explicit_start_only",
  "confidence": 0.95
}

Query: 'contracts signed until last month'
Reference Date: 2025-03-10
Timezone: UTC
Output:
{
  "start": {
    "value": null,
    "operator": null,
    "original_text": null
  },
  "end": {
    "value": "2025-02-28",
    "operator": "lte",
    "original_text": "until last month"
  },
  "is_open_ended": true,
  "boundary_type": "explicit_end_only",
  "confidence": 0.95
}

Query: 'sales data between Q1 2023 and Q3 2023'
Reference Date: 2025-01-01
Timezone: UTC
Output:
{
  "start": {
    "value": "2023-01-01",
    "operator": "gte",
    "original_text": "between Q1 2023"
  },
  "end": {
    "value": "2023-09-30",
    "operator": "lte",
    "original_text": "and Q3 2023"
  },
  "is_open_ended": false,
  "boundary_type": "explicit_range",
  "confidence": 0.95
}

Query: 'latest product specs'
Reference Date: 2025-01-15
Timezone: America/Chicago
Output:
{
  "start": {
    "value": null,
    "operator": null,
    "original_text": null
  },
  "end": {
    "value": null,
    "operator": null,
    "original_text": null
  },
  "is_open_ended": true,
  "boundary_type": "none",
  "confidence": 1.0
}

RISK_LEVEL: LOW. This prompt performs deterministic extraction. Failures produce null boundaries rather than hallucinated dates.

Adapt this template by replacing the [USER_QUERY], [REFERENCE_DATE], and [TIMEZONE] placeholders at runtime. The reference date should typically be the current date or the session's temporal anchor point. If your retrieval system uses a different filter syntax, modify the OUTPUT_SCHEMA description but preserve the operator semantics. For high-stakes retrieval pipelines where a wrong boundary could exclude critical documents, add a post-extraction validation step that checks whether the extracted range is logically consistent before constructing the metadata filter. The confidence field is your signal for when to route to human review or fall back to an unbounded search.

The Since and Until Boundary Extraction Prompt is designed to sit immediately before retrieval execution in a RAG or hybrid search pipeline. Its job is to parse explicit boundary markers like 'since January', 'until last month', or 'from 2020 onward' from a user query and produce structured start and end boundaries with operator semantics (gte, lte, gt, lt). The output is not a final answer—it is a metadata filter payload that your application layer uses to construct database WHERE clauses, vector DB filter expressions, or Elasticsearch range queries. This prompt should be called after any query rewriting or decomposition steps but before the retrieval call itself.

Integration pattern: Your application receives a user query, extracts the raw text, and passes it to this prompt along with a reference timestamp (typically now() in UTC). The model returns a JSON object with start, end, start_operator, end_operator, and an is_open_ended flag. Your harness then validates the output before constructing the retrieval filter. Key validation checks include: (1) confirm that start and end are valid ISO 8601 strings or null, (2) verify that start is not after end when both are present, (3) ensure operators are one of the allowed set (gte, gt, lte, lt), and (4) reject any output where is_open_ended is true but the query contained explicit boundary language that should have resolved to a concrete range. If validation fails, log the failure, capture the raw query and model output for debugging, and either retry with a more constrained prompt or fall back to a default recency window (e.g., last 90 days) rather than executing a broken filter.

Retry and fallback logic: When the model produces an invalid or unparseable output, implement a single retry with the same prompt but append the validation error message as additional context. For example: The previous output failed validation: start date is after end date. Please correct. If the retry also fails, do not loop indefinitely. Instead, fall back to a safe default range (e.g., no temporal filter, or a configurable default window like the past year) and emit a warning metric. This prevents a prompt failure from breaking the entire retrieval pipeline. Log every fallback event with the original query, the failed output, and the fallback range applied so you can tune the prompt or add few-shot examples for recurring failure patterns.

Metadata filter construction: Once you have a validated boundary object, map it to your specific retrieval backend. For a vector database with metadata filtering, the start and start_operator become a filter clause like {"date": {"$gte": "2024-01-01T00:00:00Z"}}. For Elasticsearch, construct a range query on your timestamp field. For SQL-backed retrieval, build a parameterized WHERE clause. Always parameterize the values rather than interpolating strings to avoid injection risks. If is_open_ended is true and only one boundary exists, construct a single-sided range filter. If both boundaries are null (the query contained no temporal language), skip the temporal filter entirely rather than applying an unnecessary constraint.

Observability and evaluation: Instrument this prompt with production tracing that captures: the raw user query, the reference timestamp used, the raw model output, validation pass/fail, retry count, fallback activation, and the final filter clause applied. For offline evaluation, maintain a golden dataset of queries with known temporal boundaries (e.g., 'since March 2024' → start=2024-03-01, end=null, start_operator=gte). Run this eval suite on every prompt change and model upgrade. Pay special attention to boundary inclusion errors—cases where the model uses gt when gte is correct, or vice versa—as these are the most common and impactful failure mode in production retrieval. If your use case involves financial, legal, or compliance documents where date precision is critical, add a human review step for any query where the model's confidence appears low or where the extracted range would filter out documents that a reasonable user would expect to see.