Confidence Decay Over Time Prompt Template

This prompt is designed for verification system architects and pipeline engineers who need to adjust a claim's confidence score based on the age of its supporting evidence. The core job-to-be-done is to prevent a verification pipeline from treating a claim as highly confident when the underlying evidence is stale, which is a common failure mode in dynamic domains like news, financial reporting, or security intelligence. You should use this prompt when you already have a base confidence score, a set of evidence items with known publication or collection timestamps, and a defined claim domain. It assumes that initial claim extraction and evidence matching have already been completed upstream.

The ideal user is integrating this prompt as a post-scoring adjustment step within a larger automated fact-checking or claims verification system. The required inputs are a [CLAIM_STATEMENT], a [BASE_CONFIDENCE_SCORE], a list of [EVIDENCE_TIMESTAMPS], and a [CLAIM_DOMAIN] to determine the appropriate decay rate. The output is a [DECAY_ADJUSTED_CONFIDENCE_SCORE] with a [TIME_SENSITIVITY_CLASSIFICATION] and a [RE_VERIFICATION_TRIGGER_DATE]. This prompt is not a replacement for initial evidence retrieval or claim matching. Do not use it for claims about static, long-settled facts (e.g., historical dates, mathematical proofs) where evidence age is irrelevant, as applying a decay function would incorrectly penalize a valid confidence score.

Before implementing this prompt, ensure your pipeline can capture and pass reliable evidence timestamps. A common failure mode is applying a decay function to evidence with a missing or default timestamp (e.g., '1970-01-01'), which will catastrophically zero out the confidence score. You should also define your domain-specific decay windows and re-verification thresholds in your application logic, not in the prompt itself, to keep the prompt's instructions stable and the parameters easily tunable. The next step after reading this section is to review the prompt template and adapt the decay function description to match your specific operational needs.

This template is designed to be pasted directly into your prompt layer. It instructs the model to adjust a claim's confidence score based on the age of its supporting evidence, the claim's time-sensitivity classification, and a defined decay function. The output is a structured JSON object containing the decay-adjusted score, the decay amount, and a re-verification trigger status. Before using this template, ensure your verification pipeline has already produced an initial confidence score, an evidence inventory with timestamps, and a time-sensitivity classification for the claim.

textCopy
You are a verification decay analyst. Your task is to adjust a claim's confidence score based on the age of its evidence.

**Inputs:**
- CLAIM: [CLAIM_TEXT]
- INITIAL_CONFIDENCE_SCORE: [INITIAL_CONFIDENCE_SCORE]
- EVIDENCE_TIMESTAMPS: [EVIDENCE_TIMESTAMPS]
- TIME_SENSITIVITY_CLASSIFICATION: [TIME_SENSITIVITY_CLASSIFICATION]
- DECAY_FUNCTION: [DECAY_FUNCTION]
- RE_VERIFICATION_THRESHOLD: [RE_VERIFICATION_THRESHOLD]

**Instructions:**
1. Calculate the age of the most recent piece of evidence from EVIDENCE_TIMESTAMPS.
2. Apply the DECAY_FUNCTION using the evidence age and the TIME_SENSITIVITY_CLASSIFICATION to determine a decay factor.
3. Multiply the INITIAL_CONFIDENCE_SCORE by the decay factor to produce the DECAY_ADJUSTED_SCORE.
4. If the DECAY_ADJUSTED_SCORE falls below the RE_VERIFICATION_THRESHOLD, set the RE_VERIFICATION_TRIGGER to `true`.
5. Output the result in the specified OUTPUT_SCHEMA.

**Constraints:**
- The DECAY_ADJUSTED_SCORE must be a float between 0.0 and 1.0.
- The DECAY_AMOUNT is calculated as INITIAL_CONFIDENCE_SCORE - DECAY_ADJUSTED_SCORE.
- If no evidence timestamps are provided, do not apply decay and set RE_VERIFICATION_TRIGGER to `true`.
- Do not explain the calculation in the output; provide only the JSON object.

**Output Schema:**
{
  "claim": "string",
  "initial_confidence_score": "float",
  "decay_adjusted_score": "float",
  "decay_amount": "float",
  "re_verification_trigger": "boolean",
  "decay_function_applied": "string"
}

To adapt this template for production, replace the square-bracket placeholders with live data from your verification pipeline. The [DECAY_FUNCTION] placeholder should be replaced with a specific, named function (e.g., linear, exponential, logarithmic) and its parameters, which your application code will use for validation. The [TIME_SENSITIVITY_CLASSIFICATION] should map to a controlled vocabulary like high, medium, or low, which determines the decay rate. After receiving the model's output, validate the JSON structure and ensure the decay_adjusted_score is mathematically consistent with the provided function before storing it. For high-stakes claims, always route outputs with a re_verification_trigger of true to a human review queue.

The Confidence Decay Over Time prompt is not a standalone widget; it is a scoring function inside a larger verification pipeline. In production, this prompt typically sits downstream of claim extraction and evidence retrieval, receiving a claim, its original confidence score, the evidence timestamp, and a decay policy. The output—a decay-adjusted confidence score with a time-sensitivity classification and a re-verification trigger—must be consumed by a stateful system that tracks claim versions over time. Do not treat this prompt as a one-shot check. It is designed to be called periodically (e.g., nightly or on-demand) against a registry of previously verified claims whose evidence is aging.

To wire this into an application, wrap the prompt in a function that accepts a ClaimRecord object with fields: claim_id, claim_text, original_confidence, evidence_timestamp, decay_policy (which defines the half-life or decay function parameters), and current_time. The function should construct the prompt using these inputs, call the model, and parse the response into a DecayAdjustedScore schema with fields: adjusted_confidence (float 0-1), time_sensitivity_class (enum: high, medium, low, stable), re_verification_trigger (boolean), and decay_rationale (string). Validate the output strictly: adjusted_confidence must be ≤ original_confidence (decay should not increase confidence), the enum must match one of the allowed values, and the rationale must reference the time delta explicitly. If validation fails, retry once with the validation error appended to the prompt as a correction hint. If the retry also fails, log the failure, flag the claim for human review, and do not update the confidence score in the database.

Observability is critical because decay decisions compound across thousands of claims. Log every invocation with: claim_id, original_confidence, evidence_timestamp, time_delta_days, adjusted_confidence, time_sensitivity_class, re_verification_trigger, model_id, prompt_version, latency_ms, and validation_passed. Emit a metric for the decay delta (original_confidence - adjusted_confidence) grouped by time_sensitivity_class so you can detect sudden shifts in decay behavior after model or prompt changes. Set up an alert if the percentage of claims triggering re_verification_trigger spikes beyond a threshold (e.g., >30% in a single batch), which may indicate a data freshness problem or a misconfigured decay policy. For model choice, a fast, cost-effective model (e.g., GPT-4o-mini, Claude Haiku) is usually sufficient because the reasoning task is bounded: compare timestamps, apply a decay function, and classify sensitivity. Reserve larger models for cases where the decay rationale is contested or escalated.

Before deploying, run the prompt against a decay validation set: a collection of claim-evidence pairs with known outcomes where you have manually labeled the expected decay behavior. Include cases where evidence is 1 day old, 30 days old, 1 year old, and 5+ years old. Include claims about fast-changing topics (e.g., stock prices, election polls) and stable facts (e.g., historical events, physical constants). The eval should check that adjusted_confidence decreases monotonically with time for time-sensitive claims and remains flat for stable claims. Also test edge cases: evidence timestamp in the future (should be rejected or flagged), missing timestamps (should return an error), and claims with no decay policy defined (should default to a conservative policy or escalate). If your system uses multiple decay policies per domain, validate that the prompt respects the policy parameters rather than applying a one-size-fits-all decay.

Finally, integrate the re-verification trigger into your pipeline's orchestration layer. When re_verification_trigger is true, the system should enqueue the claim for fresh evidence retrieval and re-scoring, not simply lower the confidence and move on. This creates a feedback loop: decay detection → re-retrieval → re-scoring → updated confidence → new decay baseline. Without this loop, decay-adjusted scores become a one-way ratchet toward zero confidence, which is both inaccurate and operationally useless. Avoid running decay prompts on claims that are already below your triage threshold; instead, route those directly to human review or archival. The decay prompt's job is to keep active claims honest, not to slowly expire your entire claim registry.