Ambiguous Date Disambiguation Prompt Template

This prompt is for integration engineers and data pipeline operators who must resolve dates from international datasets where the format is unknown or ambiguous—specifically when a numeric date like 01/02/2025 could be January 2nd (MM/DD/YYYY) or February 1st (DD/MM/YYYY). The job-to-be-done is producing a single, machine-readable ISO 8601 date with a confidence score and an auditable rationale, so that downstream systems receive a deterministic value instead of a guess. The ideal user has access to locale context (e.g., record origin country, language, or surrounding metadata) and understands that disambiguation without context is probabilistic, not deterministic.

Do not use this prompt when the source format is already known and consistent across all records—use a direct parsing library or a simpler normalization prompt instead. Do not use it for resolving relative expressions like 'next Friday' or for timezone offset correction; those are separate temporal standardization tasks. This prompt is also inappropriate when the cost of an incorrect resolution is high and no human review step exists. In regulated or financially material workflows, the prompt output must be treated as a suggestion that requires human approval before it lands in a system of record. The confidence score is a signal for routing, not a guarantee of correctness.

Before wiring this into a production pipeline, prepare a test harness with known-ambiguous cases (e.g., 03/04/2023 with locale set to US vs. UK) and measure whether the model consistently picks the correct interpretation. If your dataset contains dates that are genuinely unresolvable even with locale context (e.g., 05/05/2025 where both interpretations are valid and no metadata exists), decide ahead of time whether to flag, reject, or default to a safe fallback. The prompt template includes a [RISK_LEVEL] parameter so you can adjust the model's behavior between strict rejection and best-guess resolution depending on the downstream tolerance for error.

This template is the core instruction set you'll send to the model. It is designed to be copied directly into your prompt management system, test harness, or orchestration code. The prompt forces the model to resolve ambiguity using provided locale context, output a strict ISO 8601 date, and explain its reasoning so that a downstream system or human reviewer can audit the decision. Every variable is enclosed in square brackets—replace them with real values at runtime.

textCopy
You are a date normalization engine. Your task is to resolve an ambiguous date string into an unambiguous ISO 8601 date (YYYY-MM-DD).

## Input
Date String: [AMBIGUOUS_DATE_STRING]
Locale Hint: [LOCALE_HINT]  // e.g., 'US', 'GB', 'DE', 'JP', or 'unknown'
Contextual Clues: [CONTEXTUAL_CLUES]  // e.g., 'This is from a US-based shipping manifest dated March 2024.'

## Constraints
- If the date string is already unambiguous (e.g., YYYY-MM-DD, or day > 12), return it directly.
- If the day value is ≤ 12 and the month value is ≤ 12, use the [LOCALE_HINT] to decide the format. 'US' implies MM/DD/YYYY; 'GB', 'DE', 'FR', and most other locales imply DD/MM/YYYY.
- If [LOCALE_HINT] is 'unknown', use [CONTEXTUAL_CLUES] to infer the likely locale. If no clues exist, default to ISO 8601 rules and set confidence to 'low'.
- Do not invent dates. If the input is unparseable, set the date to null and explain why.

## Output Schema
Respond with a single JSON object conforming to this structure:
{
  "input_string": "string",
  "resolved_date": "YYYY-MM-DD | null",
  "confidence": "high | medium | low",
  "rationale": "string explaining the disambiguation decision",
  "locale_used": "string"
}

## Examples
Input: "03/04/2024", Locale: "US" -> resolved_date: "2024-03-04", confidence: "high"
Input: "03/04/2024", Locale: "GB" -> resolved_date: "2024-04-03", confidence: "high"
Input: "15/03/2024", Locale: "US" -> resolved_date: "2024-03-15", confidence: "high" (day > 12 forces DD/MM interpretation)
Input: "03/04/2024", Locale: "unknown", Context: "none" -> resolved_date: null, confidence: "low", rationale: "Ambiguous without locale hint."

## Risk Level
[RISK_LEVEL] // 'low', 'medium', or 'high'. If 'high', include a human_review_required flag in your output.

To adapt this template, start by replacing the placeholders with values from your application context. For a US-based logistics system, [LOCALE_HINT] might always be 'US', and [CONTEXTUAL_CLUES] could be pulled from a shipment's origin country field. The [RISK_LEVEL] variable should be set by your application logic: use 'high' for financial transactions or medical records where a date error has significant consequences, and 'low' for internal analytics where a small error rate is tolerable. If you need to integrate this with a validation harness, parse the output JSON and check that resolved_date is not null when confidence is 'high'. For high-risk workflows, route any output with confidence set to 'low' or 'medium' to a human review queue before the date enters your system of record.

This prompt is designed to be called as a post-extraction repair step within a data ingestion pipeline, not as a standalone user-facing feature. The typical integration pattern is: raw date strings arrive from CSV imports, API payloads, or document extraction outputs; a pre-processor identifies dates that fail strict ISO 8601 parsing or exhibit format ambiguity (e.g., values where both MM and DD are ≤ 12); those ambiguous candidates are batched and sent to this prompt with locale context attached. The prompt returns a resolved ISO 8601 date, a confidence score, and a disambiguation rationale. The application layer should never accept the resolved date without checking the confidence score against a configurable threshold.

Validation and gating logic is critical. After receiving the model output, validate that the resolved date is a valid ISO 8601 string, that the confidence score is a float between 0.0 and 1.0, and that the rationale field is a non-empty string. If confidence is below your threshold (start with 0.85 and tune based on eval results), route the record to a human review queue rather than silently accepting a low-confidence resolution. For high-volume pipelines, implement a circuit breaker: if more than 5% of records in a batch fall below threshold, halt automatic processing and alert the data quality team. Log every disambiguation decision with the original input, locale context, resolved output, confidence score, and model version for auditability.

Locale context injection is the most important implementation detail. The prompt's [CONTEXT] placeholder must be populated with the expected date format for the data source (e.g., 'US format MM/DD/YYYY', 'European format DD/MM/YYYY', or 'Unknown'). Derive this from dataset metadata, user locale settings, or upstream system configuration—never guess. If the source locale is genuinely unknown, set [CONTEXT] to 'Unknown format' and expect lower confidence scores. For multi-tenant systems, store locale-to-format mappings in a configuration table and inject them at runtime. Model selection: use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models for this task unless you've validated their performance on your specific date ambiguity patterns. Retries: if the model returns malformed JSON or a confidence score below 0.5, retry once with the same input. If the second attempt also fails, escalate to human review.

Testing and eval must happen before production deployment. Build a golden test set of at least 100 ambiguous date examples with known-correct resolutions, covering MM/DD/YYYY vs DD/MM/YYYY collisions, edge cases like '01/01/2024', and dates near month boundaries. Run the prompt against this test set and measure resolution accuracy, confidence score calibration, and refusal rate. Integrate these tests into your CI/CD pipeline so that prompt changes are validated before release. What to avoid: do not use this prompt for dates that are already unambiguous or already in ISO 8601 format—that wastes tokens and latency. Do not bypass the confidence threshold check in production, even if the model appears consistently accurate during testing. Distribution shift in input data will eventually produce failures.