Missing Date Field Extraction Prompt

This prompt is designed for document extraction pipelines where temporal data is critical and silent failures from missing dates cause downstream errors. Use it when you need to extract all date fields from a document with explicit handling for absent, ambiguous, or conflicting dates. The prompt produces normalized ISO 8601 output with uncertainty flags, absence reasons, and source citations. It belongs in production ingestion workflows for contracts, regulatory filings, financial reports, medical records, and any document type where date accuracy affects compliance, obligations, or business logic.

The ideal user is an engineering team building a structured extraction service that feeds into a database, rules engine, or compliance system. The required context includes the full unstructured or semi-structured document text, a predefined schema of expected date fields with their semantic meanings, and a tolerance policy for date ambiguity. The prompt assumes the output will be consumed by automated systems that need machine-readable date values with explicit null handling. It is not designed for simple date parsing of isolated strings or for documents where temporal precision is optional. If your pipeline only needs to find a single date in a known format, a regex or lightweight parser is more appropriate.

Do not use this prompt when the document is already in a structured format with validated date fields, when the extraction task is a one-off human review without downstream automation, or when the cost of a false positive date extraction is higher than a missed date. The prompt adds latency and token cost proportional to the number of expected date fields, so it is overkill for simple use cases. For high-risk domains such as healthcare and legal, always pair this prompt with a human review step for any field flagged with uncertainty: true or absence_reason values other than explicitly_absent. The eval harness included in the full playbook provides regression tests for date format variance, relative date resolution, and silent null detection to validate the prompt before production deployment.

This template is designed to be dropped into a document extraction pipeline where temporal accuracy is critical. It forces the model to return a structured JSON object with normalized date values, explicit null markers for every expected field, and detailed uncertainty flags when dates are missing, ambiguous, relative, or conflicting. The prompt includes a strict output schema, constraints for date normalization, and instructions for handling edge cases like partial dates, fiscal year references, and conflicting date formats within the same document. Use this as the foundation for any extraction workflow where silent date failures would cause downstream processing errors.

textCopy
You are a precise date extraction system. Your task is to extract all date fields from the provided document text and return a structured JSON object. You must normalize all dates to ISO 8601 format (YYYY-MM-DD) where possible. For every expected date field, you must return an explicit value or a null marker with a reason. You must flag any ambiguity, conflict, or missing information.

## INPUT DOCUMENT
[INPUT]

## EXPECTED DATE FIELDS
Extract the following date fields if present. For each field, determine the best value and confidence level.

[EXPECTED_FIELDS]

Example expected fields format:
- "contract_effective_date": The date the contract becomes effective
- "contract_expiration_date": The date the contract expires or terminates
- "signature_date": The date the document was signed
- "renewal_deadline": The deadline for contract renewal

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:

{
  "extraction_timestamp": "[CURRENT_TIMESTAMP]",
  "document_reference": "[DOCUMENT_ID]",
  "date_fields": {
    "[field_name]": {
      "value": "YYYY-MM-DD" | null,
      "original_text": "string | null",
      "normalization_notes": "string | null",
      "confidence": "high" | "medium" | "low" | "none",
      "absence_reason": "not_present" | "illegible" | "redacted" | "ambiguous" | "conflicting" | "relative_only" | "partial_date" | "outside_document_scope" | null,
      "alternative_interpretations": ["string"] | [],
      "requires_human_review": true | false
    }
  },
  "global_flags": {
    "has_relative_dates": true | false,
    "has_conflicting_dates": true | false,
    "has_partial_dates": true | false,
    "has_fiscal_year_references": true | false,
    "overall_completeness": "complete" | "partial" | "minimal" | "none"
  }
}

## NORMALIZATION RULES
1. Convert all dates to YYYY-MM-DD format when the full date is known.
2. For partial dates, use null for the value field and set absence_reason to "partial_date". Include the partial information in original_text.
3. For relative dates (e.g., "within 30 days of execution", "Q3 2024"), set value to null, absence_reason to "relative_only", and capture the relative expression in original_text. Add any computable anchor dates to normalization_notes.
4. For fiscal year references (e.g., "FY2024", "fiscal year ending June 30"), set value to null, set has_fiscal_year_references to true, and capture the fiscal year definition in normalization_notes.
5. When multiple conflicting dates exist for the same field, set value to null, absence_reason to "conflicting", and list all candidates in alternative_interpretations.
6. When a date is ambiguous (e.g., "01/02/2024" could be January 2 or February 1), set value to null, absence_reason to "ambiguous", and list both interpretations in alternative_interpretations.
7. For dates that are present but partially illegible, set value to null, absence_reason to "illegible", and capture any readable portions in original_text.
8. For redacted dates, set value to null, absence_reason to "redacted".

## CONFIDENCE LEVELS
- "high": Full date is explicitly stated and unambiguous
- "medium": Date is present but requires some interpretation (e.g., "the 15th of this month" with month context available)
- "low": Date is inferred from context or has significant ambiguity
- "none": Date field is absent, illegible, or completely uninterpretable

## CONSTRAINTS
[CONSTRAINTS]

Example constraints:
- Do not invent or infer dates that are not supported by the document text.
- Do not use today's date or the current year unless the document explicitly references it.
- When a date field is truly not present in the document, set value to null and absence_reason to "not_present". Do not guess.
- Flag any date that requires human review by setting requires_human_review to true.
- If the entire document contains no dates at all, set overall_completeness to "none" and return null values for all expected fields.

## EXAMPLES
[EXAMPLES]

Example input-output pairs for calibration:

Example 1: Clear date present
Input: "This Agreement is effective as of January 15, 2024."
Output for contract_effective_date: {"value": "2024-01-15", "original_text": "January 15, 2024", "normalization_notes": "Direct date conversion", "confidence": "high", "absence_reason": null, "alternative_interpretations": [], "requires_human_review": false}

Example 2: Relative date
Input: "Payment is due within 30 days of the Effective Date."
Output for payment_due_date: {"value": null, "original_text": "within 30 days of the Effective Date", "normalization_notes": "Relative to contract_effective_date. Computable if effective date is known.", "confidence": "low", "absence_reason": "relative_only", "alternative_interpretations": [], "requires_human_review": true}

Example 3: Conflicting dates
Input: "Signed this 10th day of March, 2024." and elsewhere "Execution Date: March 15, 2024"
Output for signature_date: {"value": null, "original_text": "March 10, 2024 and March 15, 2024", "normalization_notes": "Two different dates found for signature", "confidence": "none", "absence_reason": "conflicting", "alternative_interpretations": ["2024-03-10", "2024-03-15"], "requires_human_review": true}

## RISK LEVEL
[RISK_LEVEL]

Set to "high" when date accuracy is critical for legal, financial, or compliance purposes. When risk is high, default requires_human_review to true for any confidence level below "high".

To adapt this template for your pipeline, replace the square-bracket placeholders with your specific configuration. The [EXPECTED_FIELDS] placeholder should contain your complete field list with descriptions—be explicit about what each field represents to reduce extraction ambiguity. The [CONSTRAINTS] section should include any domain-specific rules, such as jurisdictional date format preferences or business rules about date ranges. The [EXAMPLES] section is critical for calibration: include at least three examples covering a clear date, a missing date, and an edge case like a relative or ambiguous date. The [RISK_LEVEL] placeholder should be set to "high" for legal, financial, or compliance documents, which will cause the model to default to human review for anything below high confidence. For lower-risk use cases like document indexing, you can set this to "medium" or "low" to reduce review overhead.

Before deploying, test this prompt against a golden dataset of documents with known date fields, including documents with missing dates, partial dates, conflicting dates, and relative date expressions. Validate that the JSON output conforms to the schema and that null values are accompanied by appropriate absence_reason values. Pay special attention to false positives—dates the model invents when none exist—and false negatives—dates the model misses entirely. These failure modes are more dangerous than incorrect date parsing because they silently corrupt downstream systems. Wire the output into a validation layer that checks schema compliance and flags any field where confidence is "low" or "none" for human review before the date enters your system of record.

The Missing Date Field Extraction Prompt is designed to be a single step within a larger document processing pipeline, not a standalone application. In production, you will typically call this prompt after layout-aware text extraction and before downstream data ingestion. The prompt expects pre-extracted text from a known document region (e.g., a contract header, an invoice body, or a form field block) passed in via the [DOCUMENT_TEXT] placeholder. Do not pass raw PDF bytes or entire multi-page documents; the model's date reasoning degrades when it must search across unrelated sections. Instead, use a pre-processing step to isolate the relevant text region, then invoke this prompt with that focused context.

Wire the prompt into your application using a structured API call (OpenAI chat completions, Anthropic Messages, or equivalent) with response_format set to json_object and the output schema defined in your system instructions. After receiving the response, run a two-layer validation pass. First, structural validation: check that the JSON parses, all required fields are present, and enum values for date_status (present, missing, ambiguous, conflicting, relative) are valid. Second, semantic validation: for any date marked present, attempt to parse the normalized_date field with a strict ISO 8601 parser (YYYY-MM-DD). If parsing fails, increment a validation_failure_count and trigger the retry path. For dates marked ambiguous or conflicting, route the record to a human review queue with the original text span and the model's uncertainty_note attached. Log every extraction attempt—including the prompt version, model ID, input hash, output, validation result, and review decision—so you can measure extraction accuracy over time and detect prompt drift.

Retry logic should be bounded and diagnostic. On a structural validation failure, retry once with the same prompt but append the validation error message to the [CONSTRAINTS] placeholder: 'Previous output failed validation: [ERROR_DETAILS]. Correct the JSON output to match the required schema.' If the second attempt also fails, log the failure and route to a manual extraction queue; do not loop indefinitely. For semantic failures where a present date cannot be parsed, do not retry automatically—the model has already signaled confidence in the date's presence, so a parse failure indicates either a normalization bug or an edge-case date format. Route these directly to human review with the raw extracted text highlighted. Model choice matters here: use a model with strong structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) for the extraction itself. A smaller, faster model can handle the validation step, but the extraction model must reliably follow the date_status enum and produce consistent ISO 8601 output.

For high-volume pipelines, implement a confidence-based routing threshold. Dates marked present with confidence >= 0.95 can bypass human review and flow directly into your database. Dates with confidence between 0.80 and 0.95 should be logged for periodic audit sampling. Anything below 0.80, plus all ambiguous, conflicting, and relative dates, must enter the review queue. Relative dates (e.g., 'effective as of the date hereof') require special handling: the model will flag them with date_status: relative and provide a relative_date_expression field, but resolution to an absolute date requires application-level logic that knows the document's reference date (signing date, filing date, etc.). Do not expect the prompt to resolve relative dates without that reference context passed in via [REFERENCE_DATE].

Finally, treat this prompt as a versioned artifact in your codebase. Store the prompt template, output schema, and validation rules together in a prompt registry. Before deploying any change to the prompt, run your evaluation suite against a golden dataset of documents with known date fields, missing dates, ambiguous formats, and conflicting dates. Measure precision and recall on date_status classification, exact-match accuracy on normalized_date for present dates, and false-negative rate on missing date detection. A silent null—where the model marks a date as missing when it is actually present in the text—is the most dangerous failure mode because it corrupts downstream temporal reasoning without an obvious error. Your eval suite must explicitly test for this case across varied date formats (US, EU, ISO, abbreviated, numeric-only) and document types.