Timestamp Anomaly Detection Prompt

This prompt is designed for data pipeline operators and fraud detection engineers who must prevent implausible timestamps from corrupting downstream analytics, billing, or audit systems. The core job-to-be-done is automated anomaly triage: taking a batch of timestamped records and producing a structured report that flags future dates in historical data, dates before the system epoch, timestamps with impossible precision (e.g., nanosecond granularity from a system that only logs seconds), and other temporal inconsistencies. The ideal user has a batch of records ready for ingestion and needs a first-pass filter to separate clean records from those requiring human review or automated repair before they enter the warehouse.

Use this prompt when you have a concrete set of records and need a structured anomaly report that includes the anomaly type, a severity classification, and a suggested correction for each flagged record. The prompt expects you to provide the records, a reference timestamp (such as the current processing time), and any known system constraints like the epoch start or maximum allowed future offset. It is not a general-purpose date formatter or timezone converter; those are separate repair workflows covered by other playbooks in this category. Do not use this prompt for simple format normalization (e.g., converting 'Jan 5, 2025' to ISO 8601) or timezone offset correction, as the prompt is tuned for plausibility checks rather than structural repair.

Before integrating this prompt into a production pipeline, you must define the severity thresholds that matter for your domain. A timestamp one day in the future might be a critical fraud signal in a financial settlement system but a minor clock-skew warning in a log aggregation pipeline. The prompt's output schema includes a severity field, but the rules that map anomaly types to severity levels should be injected via the [CONSTRAINTS] placeholder. After running the prompt, always validate the output against your expected JSON schema and log any records that the model could not classify. For high-risk domains like billing or audit, route all records with a severity of 'critical' or 'high' to a human review queue before allowing automated correction.

The following prompt template is designed to be wired into a data validation pipeline. It accepts a batch of records, a set of anomaly detection rules, and a target output schema, then returns a structured anomaly report. The placeholders in square brackets are the only parts you need to replace to make this prompt your own. Do not alter the core instruction structure unless you are prepared to re-validate the prompt's behavior against your eval suite.

textCopy
You are a temporal data quality analyst. Your task is to examine a batch of timestamped records and identify any timestamps that are implausible based on the provided constraints and business rules.

## INPUT DATA
You will receive a JSON array of records. Each record is an object that may contain one or more timestamp fields.

[INPUT_DATA]

## ANOMALY DETECTION RULES
Apply the following rules to every timestamp field in every record. Flag any timestamp that violates one or more rules.

[RULES]

## OUTPUT SCHEMA
Return ONLY a valid JSON object conforming to this exact schema. Do not include any text outside the JSON object.

[OUTPUT_SCHEMA]

## CONSTRAINTS
- Do not hallucinate anomalies. Only flag a timestamp if it violates a provided rule.
- If a timestamp field is missing or null, do not flag it as an anomaly unless a rule explicitly requires the field to be present.
- For each flagged anomaly, provide a concise, specific reason that references the rule violated.
- If no anomalies are found, return an empty anomalies array.
- Do not modify the input records. Only report anomalies.

To adapt this template, replace [INPUT_DATA] with a serialized JSON array of your records. Replace [RULES] with a bulleted list of specific, testable rules, such as "Timestamp must not be in the future relative to processing_time" or "Timestamp must be after 2020-01-01T00:00:00Z." Replace [OUTPUT_SCHEMA] with your desired JSON schema, ensuring it includes fields for record_index, field_name, anomaly_type, severity, observed_value, and reason. For high-stakes pipelines, add a [RISK_LEVEL] placeholder and a corresponding instruction to include a confidence score or escalate critical anomalies for human review. Always test the adapted prompt against a golden dataset of known anomalies before deploying it to production.

This prompt is designed to operate as a post-extraction validation gate, not a real-time streaming filter. The typical integration point is after a batch of records has been normalized (e.g., via the ISO 8601 Normalization Prompt) but before the data is written to the warehouse or used to trigger downstream events. The harness should receive a batch of records, each with a unique record_id and a timestamp field, and return a structured anomaly report. Because the model is reasoning over temporal plausibility rather than performing a deterministic calculation, the harness must treat the model's output as a high-signal advisory, not an authoritative deletion command.

Wire the prompt into a batch processing function that accepts a JSON array of records. The function should construct the prompt by injecting the records into the [INPUT_RECORDS] placeholder and specifying the [SYSTEM_EPOCH] (e.g., '2020-01-01T00:00:00Z') and [MAX_FUTURE_WINDOW_HOURS] (e.g., 24) as constraints. After receiving the model response, validate the output against a strict JSON schema that requires record_id, anomaly_type (an enum of FUTURE_DATE, BEFORE_EPOCH, IMPOSSIBLE_PRECISION, TEMPORAL_GAP), severity (LOW, MEDIUM, HIGH), and suggested_correction. Any response that fails schema validation should trigger a single retry with the validation error injected into the [PREVIOUS_ERROR] field of a retry-specific prompt variant. If the retry also fails, log the raw response and escalate the record batch for human review rather than silently dropping data.

For model choice, prefer a model with strong instruction-following and JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) because the task requires precise enum adherence and structured output. Avoid models with known weaknesses in temporal reasoning for this specific gate. Implement logging that captures the input batch hash, the model version, the full anomaly report, and the validation pass/fail status. This audit trail is critical when the harness flags a record that a downstream team believes is valid. For evaluation, maintain a golden dataset of records with known anomalies (future dates, pre-epoch timestamps, nanosecond-precision claims in a seconds-resolution system) and run the harness against it on every prompt or model version change. A regression is defined as any golden anomaly that is missed (recall drop) or any clean record that is newly flagged (precision drop). Finally, never allow the harness to auto-delete or auto-correct records in the primary data store. The anomaly report should be written to a separate anomaly_review table or queue, where an operator or a separate business-rule engine decides the corrective action.