Date Field Imputation Prompt for Missing Values

This prompt is designed for data quality engineers and ML pipeline operators who need to fill missing date fields in structured or semi-structured records. The job-to-be-done is not simple null replacement; it is evidence-based imputation that uses contextual clues from surrounding records, related fields, or temporal sequences to infer the most probable date. The ideal user has a dataset with partial temporal completeness—some records have dates, others don't—and needs a programmatic, auditable way to fill gaps before the data enters a downstream system like a reporting database, a forecasting model, or a scheduling engine. Required context includes the record with the missing date, a window of surrounding records or related fields that may contain temporal signals, and a clear definition of the target date field's meaning (e.g., order_date, ship_date, event_timestamp).

Do not use this prompt when the missing date is the primary key for a compliance or legal record where imputation would create audit risk without human review. It is also inappropriate for datasets where missingness is non-random and the absence of a date carries signal—for example, a missing close_date in a CRM might mean the deal is still open, and imputing a date would corrupt that signal. In those cases, the correct behavior is to leave the field null and handle missingness in the application layer. This prompt is also not a substitute for fixing the data collection process that produces the missing values; it is a repair step for pipelines that must tolerate incomplete upstream data.

Before deploying this prompt, prepare a holdout dataset with known dates that you artificially mask to evaluate imputation accuracy. The prompt's uncertainty score is only useful if you calibrate it against real error distributions. Start with a strict threshold: if the uncertainty score exceeds 0.3, route the record for human review rather than accepting the imputed value. As you gather production data on imputation accuracy, you can adjust this threshold or introduce automated acceptance for low-uncertainty, high-confidence cases. Never ship this prompt without a monitoring dashboard that tracks imputation rate, uncertainty distribution, and downstream impact on metrics that depend on temporal accuracy.

This section provides a copy-ready prompt template for the Date Field Imputation task. The template is designed to be dropped into an AI harness where the application layer supplies the record context, the target field, and the expected output schema. Every placeholder is marked with square brackets so you can wire in your own data, constraints, and evaluation criteria without modifying the core instruction structure. The prompt instructs the model to return not only the imputed date but also the method used, the source fields that informed the decision, and an uncertainty score—making the output auditable and testable against holdout datasets.

textCopy
You are a temporal data imputation specialist. Your task is to fill a missing date field in a record by reasoning over contextual clues from surrounding fields and related records.

## INPUT
Record with missing field: [RECORD_JSON]
Target field to impute: [TARGET_FIELD_NAME]
Surrounding records for context (optional): [SURROUNDING_RECORDS_JSON_ARRAY]
Domain context (optional): [DOMAIN_CONTEXT]

## CONSTRAINTS
- Do not invent dates that cannot be inferred from the provided context.
- If multiple plausible dates exist, return the most likely one and explain alternatives in the rationale.
- Respect any business rules provided in [BUSINESS_RULES].
- If no reasonable imputation is possible, set the imputed value to null and set the uncertainty score to 1.0.
- Prefer imputation methods in this order: direct derivation from related fields, interpolation from surrounding records, domain-typical defaults, statistical imputation.

## OUTPUT_SCHEMA
Return a JSON object with exactly these fields:
{
  "imputed_value": "ISO 8601 date string or null",
  "imputation_method": "derivation | interpolation | domain_default | statistical | none",
  "source_fields_used": ["list of field names from the record or surrounding records"],
  "uncertainty_score": 0.0-1.0,
  "rationale": "Brief explanation of how the date was determined or why imputation was not possible"
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template for your pipeline, replace each bracketed placeholder with concrete values from your application context. [RECORD_JSON] should contain the full record with the missing date field. [SURROUNDING_RECORDS_JSON_ARRAY] is optional but critical for interpolation-based imputation—supply temporally adjacent records when available. [DOMAIN_CONTEXT] can include information like 'these are e-commerce order records' or 'dates represent patient visit timestamps' to help the model select appropriate defaults. [BUSINESS_RULES] should encode constraints such as 'dates must be in the past' or 'shipment dates cannot precede order dates.' [FEW_SHOT_EXAMPLES] should include 2-4 examples covering derivation, interpolation, and no-imputation-possible scenarios. Set [RISK_LEVEL] to 'low', 'medium', or 'high' to adjust the model's conservatism—high-risk domains should bias toward null imputation when uncertainty is elevated. After adapting the template, validate outputs against a holdout dataset where you have artificially removed known dates and can measure imputation accuracy, mean absolute error, and the calibration of uncertainty scores.

Integrating the Date Field Imputation Prompt into a production pipeline requires treating it as a deterministic repair step with well-defined inputs, outputs, and failure modes. The prompt expects a structured context object containing the record with the missing date field, surrounding records for temporal context, and any business rules that constrain valid date ranges. Before calling the model, the harness should assemble this context programmatically—querying adjacent records by primary key or timestamp, injecting schema metadata about which fields are nullable, and attaching domain constraints such as 'order_date must be after customer_creation_date'. The harness should never pass raw database rows directly; instead, it should serialize only the fields relevant to imputation, explicitly marking the target field as null and labeling each provided field with its semantic meaning.

After the model returns, the harness must validate the output against a strict schema before accepting the imputed value. The expected response shape includes: imputed_date (ISO 8601 string), imputation_method (enum: interpolation, propagation, default_rule, contextual_inference), source_fields_used (array of field names), and uncertainty_score (float 0.0–1.0). A JSON Schema validator should reject responses missing required fields, containing out-of-range scores, or returning dates that violate injected business rules. If validation fails, the harness should retry once with the validation error message appended to the prompt as feedback. After two failures, the record should be routed to a dead-letter queue for human review rather than silently accepting a bad imputation. Log every imputation attempt with the record ID, model version, prompt hash, output, validation result, and latency for downstream audit and drift analysis.

Model choice matters here. This task benefits from models with strong instruction-following and structured output capabilities. For high-throughput pipelines, consider using a smaller fine-tuned model if you have a labeled dataset of known missing-value resolutions. For low-volume, high-accuracy use cases, a frontier model with strict JSON mode enabled is appropriate. If your pipeline processes records in batches, avoid sending more than 5–10 records per call—larger contexts increase the risk of the model mixing up record boundaries or hallucinating relationships. Always include a [RISK_LEVEL] parameter in the prompt: set it to high when imputing dates for compliance, financial, or clinical records, which should trigger mandatory human review regardless of confidence score. For low risk records, auto-accept imputations with uncertainty below 0.3 and log the rest for sampling. Never use imputed dates as ground truth for downstream model training without flagging them as synthetic.