Date and Timestamp Extraction Prompt from Document Metadata

This prompt is designed for document pipeline engineers who need to extract effective dates, signature dates, revision timestamps, and other metadata-level dates from documents and normalize them into ISO-8601 timestamps. The job-to-be-done is reliable, auditable date extraction that downstream systems can ingest without manual cleanup. The ideal user is building or maintaining a document intelligence pipeline—ingesting contracts, reports, filings, or forms—where date accuracy directly affects compliance, sorting, filtering, or deadline calculations.

Use this prompt when you have already extracted document metadata fields (such as effective_date, signature_date, last_modified, or revision_date) and need to resolve them into a single normalized format with source-field attribution. It is appropriate when documents may contain conflicting date fields, ambiguous formats (e.g., 03/04/2024 vs. 04/03/2024), or partial timestamps. The prompt expects structured metadata as input, not raw document text. It requires you to supply a schema of expected date fields and their priority order for conflict resolution.

Do not use this prompt for extracting dates from unstructured body text, for parsing natural-language relative dates ("next Tuesday"), or for timezone-sensitive scheduling logic. It is not a replacement for a date parsing library—it is a normalization and disambiguation layer that sits between raw extraction and database insertion. Avoid using it when the input metadata is already in a single canonical format with no conflicts; a simple transformation function will be cheaper and more reliable. For high-risk documents such as legal contracts or regulatory filings, always route low-confidence outputs to a human review queue before the normalized dates enter a system of record.

This prompt template is designed to be dropped into a document processing pipeline where you need to extract every meaningful date and timestamp from a document's metadata, header blocks, signature sections, and revision history. It forces the model to produce normalized ISO-8601 output, attribute each extracted date to its source field, and flag any ambiguity or conflict rather than silently picking a winner. The square-bracket placeholders let you adapt it to your specific document type, risk tolerance, and downstream schema without rewriting the core extraction logic.

textCopy
You are a precise date and timestamp extraction system. Your task is to extract every date and timestamp present in the provided document metadata and content, normalize them to ISO-8601 format, and return a structured JSON record with source attribution and ambiguity notes.

## INPUT
Document content with metadata fields:
[DOCUMENT_CONTENT]

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "extracted_dates": [
    {
      "date_type": "string (e.g., effective_date, signature_date, revision_date, expiration_date, created_date, metadata_date)",
      "original_value": "string (the raw text as it appears in the document)",
      "normalized_value": "string (ISO-8601 format: YYYY-MM-DD or YYYY-MM-DDThh:mm:ss±hh:mm)",
      "source_field": "string (the document field, header key, or section where this date was found)",
      "confidence": "number (0.0 to 1.0)",
      "ambiguity_notes": "string or null (explain any parsing ambiguity, conflicting formats, or assumptions made)"
    }
  ],
  "conflicts": [
    {
      "date_type": "string",
      "conflicting_values": ["string", "string"],
      "resolution_note": "string (explain the conflict and why it could not be resolved automatically)"
    }
  ],
  "extraction_metadata": {
    "total_dates_found": "number",
    "dates_with_high_confidence": "number",
    "dates_requiring_review": "number",
    "processing_note": "string (summary of any systemic issues encountered)"
  }
}

## CONSTRAINTS
- Extract ALL dates, not just the most obvious ones. Include dates from headers, footers, metadata blocks, signature lines, revision tables, and embedded document properties.
- Normalize every date to ISO-8601. For ambiguous formats (e.g., 01/02/2024), use context clues from the document to resolve month/day ordering. If unresolvable, flag it in ambiguity_notes and set confidence below 0.7.
- If the same logical date appears in multiple places with different values, record each as a separate entry and add a conflict record.
- For timestamps with timezone information, preserve the offset. For timestamps without timezone, note "no timezone specified" in ambiguity_notes.
- If a date field is present but empty or unreadable, do not include it. Do not hallucinate dates.
- Set confidence to 1.0 only when the date is unambiguous and machine-readable. Reduce confidence for OCR-derived dates, handwritten dates, or ambiguous formats.
- If [RISK_LEVEL] is "high", flag any date with confidence below 0.9 for human review.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## OUTPUT INSTRUCTIONS
Return ONLY the JSON object. No markdown fences, no commentary, no additional text.

Adaptation notes: Replace [DOCUMENT_CONTENT] with the raw text and metadata fields from your document pipeline. Set [RISK_LEVEL] to "high" for legal, financial, or compliance workflows where a wrong date has material consequences—this activates the human-review flagging logic. Populate [FEW_SHOT_EXAMPLES] with 2-4 examples from your actual document corpus showing tricky cases like multi-format dates, timezone handling, and conflicting effective dates. If your downstream system expects a different schema, modify the OUTPUT_SCHEMA block but preserve the source_field, confidence, and ambiguity_notes fields—these are what make the extraction auditable. For production, pair this prompt with a JSON schema validator that rejects malformed output and triggers a retry with the error message appended to the prompt.

This prompt is designed to be called after document text and metadata have been extracted from the source file (PDF, DOCX, email, etc.) but before the normalized dates are written to your target system. The harness should pass the raw document metadata dictionary and the extracted body text as structured inputs, not as a single flat string. Keep the metadata fields separate so the model can attribute each extracted date to its source field (e.g., pdf:created, exiftool:DateTimeOriginal, email:Date). The prompt expects a JSON output matching the defined schema, which your harness must validate before ingestion.

Validation and retry logic: Parse the model's JSON output and validate it against the expected schema. Check that every iso8601 field is a valid ISO-8601 string, that source_field references a real input field, and that ambiguity_notes is present when confidence is below your threshold (we recommend 0.85). If validation fails, retry once with the validation error message appended to the prompt as additional context. If the retry also fails, route the document to a human review queue with the raw metadata, extracted text, and both failed outputs attached. Do not silently drop dates or fall back to a best-guess without logging the ambiguity.

Model choice and tool use: This extraction task works well with capable mid-tier models (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro) because it requires structured output adherence and reasoning about temporal ambiguity. If your pipeline processes high volumes, consider using a faster model for the initial extraction and a stronger model for the retry-on-failure path. Do not use function calling for this prompt—the output is a data payload, not an action. The model should return the JSON directly. For documents with embedded timestamps in multiple time zones, include a [TIMEZONE_HINT] variable in the prompt to reduce ambiguity.

Logging and observability: Log every extraction attempt with the document ID, model version, prompt version, raw output, validation result, and final ingested dates. This audit trail is critical when downstream systems rely on extracted effective dates, signature dates, or revision timestamps. If you detect a pattern of low-confidence extractions from a specific document source or format, use those logs to improve your preprocessing or add few-shot examples to the prompt. Never assume the model's date normalization is correct without comparing extracted dates against known document events where ground truth is available.