Publication Date Extraction Prompt for Unstructured Documents

This prompt is designed for data pipeline builders and document intelligence engineers who need to extract reliable temporal metadata from unstructured documents such as articles, regulatory filings, reports, and web pages. The core job-to-be-done is converting messy, inconsistently formatted date information into normalized ISO 8601 timestamps with confidence scores and extraction provenance. Downstream systems—search indexes, compliance archives, RAG retrieval pipelines, and analytics dashboards—depend on this temporal metadata for filtering, ranking, and audit trails. The ideal user is someone integrating this extraction step into an automated ingestion pipeline where manual date tagging doesn't scale.

Use this prompt when your documents contain explicit or implicit date signals in text form: bylines, 'Published on' lines, 'Last updated' footers, copyright dates, or effective-date clauses. The prompt handles common ambiguities including multiple date candidates, relative timestamps ('3 days ago'), and regional format variations (MM/DD/YYYY vs DD/MM/YYYY). It is not suitable for real-time streaming data timestamping where the system clock is the authoritative source, nor for documents where dates exist only as images without OCR preprocessing. For scanned PDFs or image-heavy documents, ensure an OCR pipeline runs before this extraction step.

Before deploying this prompt, confirm that your pipeline can handle the output schema: each extracted date includes a date_type classification (publication, last_updated, effective), an ISO 8601 timestamp, a confidence score between 0 and 1, and an extraction_provenance field citing the exact text span that produced the date. For high-stakes use cases such as regulatory compliance or legal filings, always route low-confidence extractions (below your defined threshold) to human review. Pair this prompt with the Temporal Hallucination Detection Prompt from this content group to catch fabricated dates before they enter your knowledge base.

This prompt template is designed for document intelligence pipelines that need to extract temporal metadata from unstructured documents such as articles, regulatory filings, reports, and web pages. It instructs the model to identify three distinct date types—publication, last-updated, and effective—and return them as normalized ISO 8601 timestamps. Each extracted date is accompanied by a confidence score and the exact text span used for extraction, providing the provenance required for downstream audit and verification. The prompt is structured to handle missing dates gracefully by returning null values with explicit reasons rather than hallucinating or defaulting to the current date.

textCopy
You are a precise date extraction system. Your task is to extract publication, last-updated, and effective dates from the provided document text.

## INPUT
[INPUT]

## OUTPUT SCHEMA
Return a single JSON object with the following structure. Do not include any text outside the JSON object.
{
  "publication_date": {
    "value": "ISO 8601 timestamp or null",
    "confidence": 0.0 to 1.0,
    "source_span": "exact text used for extraction or null",
    "reason": "explanation if null"
  },
  "last_updated_date": {
    "value": "ISO 8601 timestamp or null",
    "confidence": 0.0 to 1.0,
    "source_span": "exact text used for extraction or null",
    "reason": "explanation if null"
  },
  "effective_date": {
    "value": "ISO 8601 timestamp or null",
    "confidence": 0.0 to 1.0,
    "source_span": "exact text used for extraction or null",
    "reason": "explanation if null"
  }
}

## CONSTRAINTS
[CONSTRAINTS]
- All dates must be normalized to ISO 8601 format (YYYY-MM-DD or YYYY-MM-DDThh:mm:ss±hh:mm).
- If a date is incomplete (e.g., year only), use the first day of the period (e.g., 2024 becomes 2024-01-01) and set confidence below 0.5.
- Distinguish between "last updated" (content modified after initial publication) and "effective date" (when the content takes effect, common in legal and policy documents).
- If multiple dates of the same type are found, select the most specific and document the choice in the reason field.
- If no date of a given type is found, set value to null, confidence to 0.0, and provide a brief reason.
- Do not infer dates from the current date, filename, or external metadata not present in the text.
- For relative timestamps (e.g., "yesterday", "last quarter"), convert to an absolute date only if the reference point is unambiguously stated in the text. Otherwise, return null with reason "relative timestamp without anchor".
- Confidence scores: 0.9-1.0 for explicit, unambiguous dates; 0.7-0.89 for clear but non-standard formats; 0.5-0.69 for inferred or partial dates; below 0.5 for ambiguous or incomplete extractions.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific requirements. The [INPUT] placeholder should receive the raw document text, preprocessed to remove any binary artifacts but preserving the original formatting where possible. The [CONSTRAINTS] section can be extended with domain-specific rules—for example, financial filings may require handling of fiscal year conventions, while news articles may need timezone normalization. The [EXAMPLES] placeholder should be populated with 2-4 few-shot examples that demonstrate the expected behavior for your document types, including edge cases like missing dates, ambiguous formats, and relative timestamps. The [RISK_LEVEL] field should be set to "high" if downstream decisions depend on date accuracy, triggering additional validation and human review steps in your pipeline. For production use, always pair this prompt with a JSON schema validator and a confidence threshold that routes low-confidence extractions to a human review queue.

This prompt is designed to be a single step inside a larger document intelligence pipeline. It should receive pre-extracted text from a document parser (such as a PDF reader, web scraper, or OCR engine) rather than raw binary files. The calling application is responsible for chunking long documents, managing rate limits, and handling model unavailability. The prompt itself is stateless and idempotent: given the same text input and constraints, it should produce the same structured output.

The integration pattern follows a validate-then-store loop. After the model returns a JSON response, the application must validate it against the expected schema before writing to the data store. Key validation checks include: (1) all date_type values are from the allowed enum (publication, last_updated, effective, copyright, other); (2) all iso_8601 fields parse to valid dates; (3) confidence values are floats between 0.0 and 1.0; and (4) extraction_provenance contains at least one non-empty string. If validation fails, the application should retry the prompt once with the validation error appended to the [CONSTRAINTS] block. If the retry also fails, log the failure, store the raw model output for debugging, and route the document to a human review queue. For high-volume pipelines, consider using a cheaper, faster model (e.g., GPT-4o-mini or Claude Haiku) for the initial extraction, escalating to a more capable model only when confidence scores fall below a configured threshold (e.g., 0.7).

Observability is critical because date extraction failures silently corrupt downstream temporal reasoning. At minimum, log the document identifier, prompt version, model used, extracted dates, confidence scores, and validation status for every extraction. Emit a structured log event or trace span that can be queried later. Set up alerts for sudden drops in extraction success rate or spikes in low-confidence outputs, as these often indicate upstream document format changes or model behavior drift. For audit-heavy domains (legal, financial, compliance), persist the full prompt and response pair as an immutable record. Avoid storing the raw document text in logs to reduce PII and data retention risk; the document identifier is sufficient for traceability. Before deploying a prompt change, run the new version against a golden dataset of 50-100 documents with known publication dates and verify that extraction accuracy does not regress.