Retraction and Correction Status Check Prompt

This prompt is designed for evidence pipeline engineers and trust-and-safety teams who need to prevent AI systems from citing invalidated, retracted, or superseded sources. The primary job-to-be-done is programmatic verification: given a source identifier (DOI, URL, title, or citation string), the prompt instructs the model to check known retraction databases, publisher correction notices, and version histories to determine whether the source remains valid evidence. The ideal user is a developer building a RAG ingestion pipeline, a scientific review assistant, or a legal-tech application where citing retracted content carries regulatory or reputational risk. Required context includes the source metadata, the domain of use (e.g., medical, legal, scientific), and the acceptable staleness threshold for correction checks.

Do not use this prompt as a standalone fact-checker for claims within a source. It checks the status of the source container—retraction, correction, expression of concern, or supersession—not the truth of individual statements. It is also not a substitute for a live retraction database API. The prompt works best when combined with a retrieval step that queries databases like PubMed, Retraction Watch, or CrossRef, and then uses the model to interpret and structure the results. For high-stakes domains like clinical medicine or appellate law, always require human review of the final status determination and maintain an audit log of which version of the prompt and which databases were consulted.

Before implementing, define your failure modes: a false negative (missing a retraction) is far more dangerous than a false positive (flagging a clean source). Structure your evaluation harness to test against a golden dataset of known retracted, corrected, and clean sources. If your pipeline processes more than 100 sources per hour, pair this prompt with a caching layer for retraction status and a batch-scoring variant to control latency and cost. The next section provides the copy-ready template you can adapt to your specific evidence pipeline.

This prompt template is designed to be dropped into an evidence pipeline before a source is used for grounding. It accepts a source identifier and any available metadata, then instructs the model to check for retraction, correction, or supersession status. The template uses square-bracket placeholders so you can wire it into your application without manual rewriting. Every placeholder maps to a field your pipeline should populate before sending the request.

textCopy
You are a source integrity checker for an evidence pipeline. Your job is to determine whether a given source has been retracted, corrected, or superseded. Do not evaluate the source's claims or quality. Only check its publication status.

SOURCE TO CHECK:
- Title: [SOURCE_TITLE]
- Authors: [SOURCE_AUTHORS]
- Publication Venue: [SOURCE_VENUE]
- Publication Date: [SOURCE_DATE]
- DOI or Identifier: [SOURCE_IDENTIFIER]
- URL: [SOURCE_URL]
- Abstract or Snippet: [SOURCE_SNIPPET]

RETRACTION DATABASES TO CONSULT:
[RETRACTION_DATABASES]

CORRECTION AND VERSION HISTORY SOURCES:
[CORRECTION_SOURCES]

OUTPUT SCHEMA:
Return a JSON object with these fields:
- status: One of "retracted", "corrected", "superseded", "active", "unknown"
- confidence: One of "high", "medium", "low", "insufficient_data"
- evidence: Array of objects with fields "source" (where the status was found), "type" (retraction_notice, correction_notice, version_history, supersession_notice, publisher_statement), "url" (link to the notice if available), "summary" (one-sentence description of what was found)
- retraction_reason: If retracted, the stated reason. Null otherwise.
- correction_scope: If corrected, what was changed. Null otherwise.
- superseded_by: If superseded, the identifier or title of the replacement. Null otherwise.
- last_verified_date: The date of the most recent status check you can confirm
- notes: Any caveats about data availability or conflicting signals

CONSTRAINTS:
- If you cannot access a retraction database, state that in the notes field and set confidence to "low" or "insufficient_data".
- Do not infer retraction from criticism or disagreement. Only report formal retractions, corrections, or supersessions.
- If multiple sources conflict, report all evidence and set confidence accordingly.
- If the source has a version history indicating a newer version exists, classify as "superseded".
- If the publication date is missing and you cannot verify status, set status to "unknown" and confidence to "insufficient_data".

RISK LEVEL: [RISK_LEVEL]

EXAMPLES:
[EXAMPLES]

Adapting the template. Replace each placeholder with values from your pipeline. [RETRACTION_DATABASES] should list the specific databases you want checked (e.g., Retraction Watch, PubMed, Crossref). [CORRECTION_SOURCES] should specify where to look for corrections and version histories (e.g., publisher websites, preprint servers, version control repositories). [RISK_LEVEL] accepts values like high, medium, or low and should adjust the model's thoroughness expectations—high-risk domains like clinical evidence should trigger more exhaustive checking language. [EXAMPLES] is optional but recommended: provide one or two few-shot examples showing correct output for known retracted or corrected sources to calibrate the model's behavior. If your pipeline already has source metadata, wire those fields directly into [SOURCE_TITLE] through [SOURCE_SNIPPET]. Leave any unknown fields as empty strings rather than removing them, so the model sees the full schema.

Validation and safety. The output JSON must be validated before downstream use. Check that status is one of the five allowed values and that confidence matches the evidence array length—a high confidence with zero evidence items is a validation failure. In high-risk domains, route retracted and corrected results for human review before blocking the source. For unknown status with low confidence, decide whether your pipeline should treat the source as admissible with a warning or block it until manual verification. Never silently pass a source with status: "unknown" into a citation or answer-generation step without explicit policy handling.

The retraction and correction status check prompt is designed to operate as a pre-citation gate in an evidence pipeline, not as a standalone chat interaction. Before any retrieved source is used to ground an answer or generate a citation, this prompt should be called to verify whether the source has been retracted, corrected, or superseded. The implementation harness must treat this check as a blocking step: if the prompt returns a status of retracted or superseded, the source must be excluded from downstream answer generation and logged for audit review. If the status is corrected, the pipeline should attempt to retrieve the corrected version before proceeding.

Wire this prompt as a synchronous API call within your retrieval-augmented generation (RAG) pipeline, placed after document retrieval but before evidence ranking or answer synthesis. The input payload should include the source DOI, title, authors, publication date, and any available retraction database identifiers. The model should return a structured JSON object with fields: status (enum: valid, corrected, retracted, superseded, unknown), confidence (0-1 float), evidence (array of strings citing retraction notices or correction records), and corrected_source_identifier (string or null). Validate the output schema before allowing the pipeline to proceed. If confidence is below your configured threshold (we recommend 0.7 for high-risk domains), route the source to a human review queue rather than silently accepting an unknown status. Implement retry logic with exponential backoff for transient model API failures, but cap retries at three attempts before escalating to manual review.

For scientific and medical domains, integrate this prompt with external retraction databases such as PubMed's retraction index, Retraction Watch, and Crossref's retraction metadata API. The prompt should receive pre-fetched database results as part of its [CONTEXT] input rather than relying on the model's parametric knowledge, which may be outdated. In legal domains, cross-reference with court docket systems and citation services like Shepard's to detect overturned or superseded precedents. Log every check result with the source identifier, timestamp, model version, and final disposition for audit trails. Avoid implementing this as a fire-and-forget step: stale retraction data in your pipeline is a compliance risk, so schedule periodic re-checks of previously validated sources, especially for content older than six months in fast-moving fields.