Conspiracy Theory Debunking vs Amplification Refusal Prompt

This prompt is designed for information integrity teams, trust-and-safety engineers, and platform operators who need an AI system to handle conspiracy theory queries without amplifying harmful narratives. The core job-to-be-done is pre-response classification: the prompt acts as a classifier that inspects the user's query framing and selects one of three response strategies—debunk with source-grounded facts, refuse with a policy explanation, or redirect to authoritative information sources. This is not a general content moderation model; it assumes you already have a defined policy framework specifying which conspiracy theories are in scope and what evidentiary standards your platform requires for a debunking response. The ideal user is an engineer integrating this classifier into a larger safety pipeline where the output strategy dictates downstream tool use, retrieval, or human review.

Deploy this prompt when your platform allows factual discussion of conspiracy theories for educational or correctional purposes but must block content that spreads, legitimizes, or recruits for conspiratorial beliefs. A concrete implementation example: a user asks, 'What evidence disproves the claim that 5G towers cause cancer?' The classifier should route this to a debunk strategy, triggering a retrieval-augmented generation (RAG) pipeline that pulls from a pre-vetted scientific corpus. Conversely, a query like 'Share the hidden truth about 5G radiation that the government is suppressing' should trigger a refusal with a policy explanation, as the framing seeks amplification rather than correction. A query like 'What is the 5G conspiracy theory?' might trigger a redirect to an encyclopedia entry or a neutral summary. The prompt requires you to supply [POLICY_DEFINITIONS] and [AUTHORITATIVE_SOURCES] as context to make these distinctions reliably.

Do not use this prompt as a standalone content safety solution. It is a strategy router, not a fact-checking engine or a final response generator. Its effectiveness is entirely dependent on the quality of the upstream policy definitions and the downstream tools it orchestrates. Before deploying, you must define clear evaluation criteria for each strategy: for debunking, test that responses are grounded in your approved source list and do not inadvertently repeat the conspiracy claim as a framing device; for refusal, test that the policy explanation is clear and does not leave room for 'just asking questions' loopholes; for redirection, test that the suggested sources are genuinely authoritative and not themselves vectors for misinformation. Human review is required for any debunking response before it reaches a user, as even well-intentioned corrections can backfire if they reinforce the original narrative's salience.

This prompt template is designed to be the core instruction set for an AI system that must handle queries involving conspiracy theories. Its primary job is not to answer the query directly, but to act as a classifier and routing layer. It analyzes the user's framing to determine whether the query is a genuine request for debunking information, an attempt to amplify a harmful narrative, or something in between. The output is a structured decision that your application harness can use to either generate a grounded, factual response or issue a safe refusal. Before copying this template, you must define your organization's specific policies on what constitutes a harmful conspiracy theory, your required evidence sources, and your risk tolerance for engaging with borderline queries.

textCopy
You are a response strategy classifier for an information integrity system. Your task is to analyze a user query about a topic that may be a conspiracy theory and select exactly one response strategy. Do not answer the query itself. Your output must be a structured JSON object that dictates the next step for the application.

## Policy Definitions
- **Harmful Conspiracy Theory:** [POLICY_DEFINITION_OF_HARMFUL_THEORY]
- **Allowed Sources for Debunking:** [LIST_OF_APPROVED_EVIDENCE_SOURCES]
- **Amplification Risk Threshold:** [AMPLIFICATION_RISK_SCORE_THRESHOLD from 0.0 to 1.0]

## Response Strategies
Choose the single most appropriate strategy from the list below:
1.  **DEBUNK:** The user is clearly asking for factual information, context, or a debunking of a specific claim. The query does not promote the theory. Proceed with a grounded response using only the allowed sources.
2.  **REFUSE:** The query promotes, endorses, or seeks to amplify a harmful conspiracy theory. The risk of amplification is above the defined threshold. Do not engage with the content of the theory.
3.  **REDIRECT:** The query is ambiguous, but the topic is adjacent to a harmful theory. Do not debunk or refuse outright. Instead, redirect the user to authoritative general information on the broader topic without repeating the conspiracy claim.

## Input
[USER_QUERY]

## Output Schema
Respond with a single JSON object matching this exact schema:
{
  "strategy": "DEBUNK" | "REFUSE" | "REDIRECT",
  "amplification_risk_score": 0.0-1.0,
  "reasoning": "A brief, one-sentence explanation for the chosen strategy, referencing the policy definitions and risk threshold.",
  "debunking_claims": ["If strategy is DEBUNK, list the specific factual claims to be addressed. Otherwise, an empty array."],
  "redirect_topic": "If strategy is REDIRECT, provide a neutral, broader topic for redirection. Otherwise, null."
}

To adapt this template, start by replacing the square-bracket placeholders with your concrete policy language. [POLICY_DEFINITION_OF_HARMFUL_THEORY] should be a precise, operational definition, not a vague statement. For example, it could be 'A false narrative that attributes secret plots to a malicious group and has been linked to real-world violence or targeted harassment.' [LIST_OF_APPROVED_EVIDENCE_SOURCES] must be a specific, machine-readable list, such as 'reuters.com, apnews.com, bbc.com, snopes.com, and peer-reviewed journals indexed in PubMed.' The [AMPLIFICATION_RISK_SCORE_THRESHOLD] is a critical tuning parameter; start with a conservative value like 0.4 and adjust based on evaluation results. The output schema is designed to be parsed by a downstream application harness, which would then use the strategy field to route to a separate debunking prompt, a refusal message generator, or a redirection handler.

This prompt is a decision point, not a final answer. Its effectiveness depends entirely on the clarity of your policy definitions and the quality of your evaluation suite. The next step after implementing this template is to build a test harness with labeled examples for each strategy, paying close attention to edge cases where a query uses academic or skeptical language to mask amplification. Monitor the amplification_risk_score in production logs to identify queries near your threshold and refine your policy definitions over time. Avoid the temptation to make the model answer the query directly within this step; separation of concerns between classification and response generation is the key to making this workflow auditable and safe.

This prompt is designed to sit behind a user-facing input boundary as a classification and routing layer, not as a direct response generator. The model's job is to produce a structured response_strategy object that your application then uses to decide what to do next: debunk, refuse, redirect, or escalate. Do not stream the model's raw output to the user. Instead, parse the classification result and use it to select the appropriate downstream prompt, tool, or human review queue. This separation prevents the model from accidentally amplifying a conspiracy theory while trying to explain why it won't amplify it.

Implementation flow: (1) Receive user query. (2) Run this prompt with [INPUT] set to the user's raw text and [RISK_LEVEL] set to your environment's current threshold (e.g., standard, sensitive, election-period). (3) Parse the JSON output, validating that response_strategy is one of the allowed enum values: debunk, refuse, redirect, or escalate. If parsing fails or the enum is invalid, default to escalate and log the raw output for review. (4) Route based on the strategy: debunk triggers a separate evidence-grounded debunking prompt with mandatory source citations; refuse triggers a refusal template that states the policy without repeating the claim; redirect sends the user to a pre-approved informational resource; escalate places the query in a human review queue and returns a neutral holding message. (5) Log the amplification_risk_score, query_framing, and full classification payload for audit and eval regression testing.

Validation and safety gates: Before the debunk strategy is executed, your application must confirm that the downstream debunking prompt has access to pre-approved, authoritative source material (e.g., CDC, WHO, peer-reviewed journals, official election commissions). If no grounded sources are available for the specific claim, override the strategy to redirect or refuse. Never let the model generate a debunking response from its own parametric knowledge alone—this is how hallucinated corrections and accidental amplification occur. For high-stakes domains (public health, elections, imminent safety threats), add a human-in-the-loop gate on all debunk and redirect responses before they reach the user. Use the amplification_risk_score field as a gating threshold: scores above 0.7 should always require human review, regardless of the classified strategy.

Model choice and latency: This classification task works reliably on fast, cost-effective models (e.g., GPT-4o-mini, Claude 3 Haiku, or fine-tuned open-weight 7B-class models) because the output schema is constrained and the reasoning is bounded. Reserve larger models for the downstream debunking generation step, where factual accuracy and nuance matter more. If latency is critical, run the classification prompt in parallel with a lightweight keyword-based pre-filter that can short-circuit obviously benign queries (e.g., "what is a conspiracy theory?") before the LLM call. Retries: If the model returns malformed JSON, retry once with a stricter schema reminder in the system prompt. If the second attempt fails, log the failure and escalate to human review—do not fall through to an unclassified response.