Deprecation and Retraction Detection Prompt

This prompt is designed for verification pipelines that must not cite withdrawn, superseded, or silently corrected sources. The core job is to take a source identifier and its metadata, then return a structured deprecation status indicating whether the source is active, retracted, superseded, or partially corrected. The ideal user is a verification engineer or pipeline operator who needs to programmatically filter evidence before it enters a fact-checking or RAG workflow. Required context includes the source title, publication date, publisher, and any available retraction or correction notices. Without this metadata, the prompt cannot reliably detect deprecation signals.

Use this prompt when your system ingests sources that may change over time—journal articles with retractions, regulatory guidance that gets superseded, technical documentation with errata, or news articles with silent corrections. It is particularly valuable in high-stakes domains like healthcare, finance, and legal verification, where citing an outdated or withdrawn source can cause real harm. The prompt is designed to detect both explicit retraction notices and subtler signals like publisher-issued corrections, version deprecation markers, and superseding document references. It also flags cases where a source has been partially corrected but not fully withdrawn, which is a common failure mode in naive deprecation checks.

Do not use this prompt as a substitute for direct API queries to retraction databases like PubMed's retraction index or Crossmark when those are available. The prompt works best as a secondary check on sources that have already passed through structured validation, or as a primary check when structured retraction data is unavailable. It is not designed to detect deliberate fraud or fabrication in sources—that requires separate adversarial verification workflows. For high-risk verification, always route outputs flagged as 'retracted' or 'superseded' to human review before blocking a source from your pipeline. A false positive on retraction detection can silently remove valid evidence from your system, which is as dangerous as a false negative.

Before deploying this prompt, prepare a test set of sources with known retraction statuses, including edge cases like partial corrections, superseding documents that don't explicitly retract the original, and sources where retraction notices exist but are not linked from the source metadata. These edge cases are where the prompt is most likely to fail. Wire the output into your evidence filtering logic so that sources flagged as 'retracted' or 'superseded' are either blocked or routed for review, not silently passed through. The next section provides the copy-ready prompt template you can adapt to your source metadata schema.

This prompt template is designed to be dropped into a verification pipeline where source freshness and integrity are critical. It instructs the model to examine a provided source for explicit retraction notices, deprecation markers, or superseding publications, and to produce a structured assessment. The template uses square-bracket placeholders for all dynamic inputs, making it safe to template in code before sending to the model.

textCopy
You are a source integrity analyst. Your task is to examine the provided source and determine its deprecation or retraction status. You must not cite withdrawn, retracted, or superseded sources as authoritative evidence.

## INPUT
Source Content or Metadata: [SOURCE_TEXT]
Source Type: [SOURCE_TYPE]  // e.g., 'journal_article', 'preprint', 'technical_documentation', 'news_report', 'regulatory_filing'
Verification Date: [VERIFICATION_DATE]  // ISO 8601 date when this check is performed

## CONSTRAINTS
- Only flag a source as retracted or deprecated if there is explicit evidence in the provided content or metadata.
- Distinguish between 'retracted' (withdrawn due to error or misconduct), 'deprecated' (replaced by a newer version), 'superseded' (made obsolete by a later publication), and 'active' (no issues found).
- If a retraction notice or deprecation marker is found, extract the reason and any cited superseding source.
- If no explicit evidence is found, the status must be 'active' with a note that absence of evidence is not evidence of validity.
- Do not infer deprecation from age alone. A source is not deprecated simply because it is old.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "status": "retracted" | "deprecated" | "superseded" | "active" | "uncertain",
  "confidence": 0.0-1.0,
  "evidence": [
    {
      "type": "retraction_notice" | "deprecation_marker" | "superseding_citation" | "version_history" | "publisher_statement" | "other",
      "excerpt": "string",
      "location": "string"  // where in the source this evidence was found
    }
  ],
  "retraction_reason": "string | null",
  "superseding_source": {
    "title": "string | null",
    "identifier": "string | null",  // DOI, URL, or other persistent identifier
    "relationship": "direct_replacement" | "newer_version" | "correction" | "null"
  },
  "partial_correction": true | false,  // true if only part of the source was corrected, not fully retracted
  "notes": "string"
}

## EXAMPLES
Example 1 - Retracted Article:
Input: "RETRACTION NOTICE: The authors have retracted this article due to data fabrication. See DOI: 10.1234/retraction-notice."
Output: {"status": "retracted", "confidence": 0.99, "evidence": [{"type": "retraction_notice", "excerpt": "RETRACTION NOTICE: The authors have retracted this article due to data fabrication.", "location": "header"}], "retraction_reason": "data fabrication", "superseding_source": {"title": null, "identifier": "10.1234/retraction-notice", "relationship": "correction"}, "partial_correction": false, "notes": "Full retraction with explicit notice."}

Example 2 - Deprecated Documentation:
Input: "DEPRECATED: This API version is no longer supported. Use v3.0 instead at https://docs.example.com/v3."
Output: {"status": "deprecated", "confidence": 0.99, "evidence": [{"type": "deprecation_marker", "excerpt": "DEPRECATED: This API version is no longer supported.", "location": "top of document"}], "retraction_reason": null, "superseding_source": {"title": "API v3.0 Documentation", "identifier": "https://docs.example.com/v3", "relationship": "newer_version"}, "partial_correction": false, "notes": "Explicit deprecation with replacement link."}

Example 3 - Active Source:
Input: "Published 2019. No retraction or correction notices found."
Output: {"status": "active", "confidence": 0.85, "evidence": [], "retraction_reason": null, "superseding_source": null, "partial_correction": false, "notes": "No explicit deprecation or retraction evidence found in provided content. Absence of evidence is not evidence of validity."}

## RISK_LEVEL
[RISK_LEVEL]  // 'low', 'medium', 'high', 'critical' - affects how strictly the model should interpret ambiguous signals

To adapt this template, replace the square-bracket placeholders with values from your source metadata store and verification context. The [SOURCE_TEXT] should include the full text or metadata you want to check—do not truncate retraction notices or version history sections. The [RISK_LEVEL] parameter controls the model's behavior: at 'critical' risk, the model should treat any ambiguity as a potential deprecation signal and flag it for human review; at 'low' risk, it should only flag explicit, unambiguous markers. Wire the [VERIFICATION_DATE] to your system clock so audit trails capture when the check was performed. The output schema is designed for direct ingestion into a verification database—validate the JSON structure before storing, and log any parse failures for prompt debugging.

This prompt is designed to be called before any source is used as evidence in a fact-checking workflow. The implementation harness should treat it as a synchronous gate: a source that returns a status of retracted or superseded must be blocked from downstream evidence matching and citation generation. The prompt expects a structured input payload containing the source metadata you have available—typically a title, URL, publication date, and any retraction or correction notices scraped from the page. In production, you will often call this prompt after a retrieval step but before evidence ranking, making it a critical chokepoint where latency must be kept low.

Wire the prompt into your application as a typed function call with strict input and output schemas. The input schema should accept source_metadata (object with fields like title, url, publication_date, publisher, authors, and raw_notices), plus an optional [CONTEXT] block for any surrounding pipeline information. The output schema must enforce the DeprecationAssessment contract: a status enum of active, superseded, retracted, corrected, or unknown; a confidence score between 0.0 and 1.0; a retraction_notice_detected boolean; a superseding_source object with title, url, and relationship fields; and an evidence array of strings citing exactly what in the input led to the determination. Validate this output with a JSON schema validator before allowing the result to influence downstream routing. If validation fails, retry once with a repair prompt that includes the validation error; if it fails again, route the source to a human review queue with the raw metadata and both failed outputs attached.

Model choice matters here. This task requires careful reading of retraction notices, correction statements, and cross-referencing of superseding source indicators—capabilities where larger frontier models (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro) significantly outperform smaller or older models. For high-throughput pipelines, consider a tiered routing pattern: use a fast, cheap model for obvious cases (clear retraction banners, well-known retracted DOIs) and escalate ambiguous cases to a more capable model. Log every assessment with the model version, prompt hash, input metadata, output, and downstream action taken. This audit trail is essential for debugging false negatives—cases where a retracted source slipped through—and for demonstrating due diligence to compliance reviewers. For sources flagged as corrected, implement a follow-up step that fetches the correction notice content and re-evaluates whether the specific claims you intend to cite are affected by the correction, rather than discarding the source entirely.

The highest-risk failure mode in production is the silent retraction: a source that has been withdrawn or superseded but carries no machine-readable or visually prominent retraction notice. Your harness should not rely solely on this prompt for safety. Combine it with external signals where available: check the Crossref and PubMed retraction APIs for academic sources, monitor retraction databases like Retraction Watch, and maintain an internal denylist of known retracted sources that bypasses the LLM entirely. The prompt is your semantic understanding layer—it reads the nuanced language of correction notices and editorial statements—but it should be one layer in a defense-in-depth strategy. When the prompt returns unknown with low confidence, default to conservative handling: flag the source for human review rather than treating it as safe. Finally, schedule regular eval runs against your golden dataset of known retracted, superseded, and corrected sources to detect model drift or prompt degradation before it affects live verification decisions.