Deliberate Deception Pattern Recognition Prompt

This prompt is a pre-deployment diagnostic, not a production fact-checker. Its job is to take a single claim that has been deliberately crafted to exploit a known disinformation technique—paltering, false implication, category error, motte-and-bailey, and others—and output a structured classification. The primary user is a verification QA engineer or red-team tester who needs to answer a specific question: 'Does my downstream verification pipeline recognize this class of deception, or does it slip through?' Use it during the adversarial testing phase to build a heat map of your system's weaknesses before you ship.

Do not use this prompt inside a live verification product. It is not designed to verify truth; it is designed to classify the structure of the deception. A production fact-checker must match claims against evidence and return a supported/refuted/unverified determination. This prompt, by contrast, returns a pattern label, a confidence score, and a concise rationale for why the input fits a particular deception technique. The output is a diagnostic signal for you, the engineer, indicating where to harden your extraction rules, evidence-matching logic, or refusal boundaries. For example, if this prompt consistently flags 'motte-and-bailey' patterns but your production verifier treats them as straightforward factual claims, you have identified a hardening target.

Integrate this prompt into a red-team test harness, not a user-facing application. Feed it a labeled dataset of adversarial claims, compare its classifications against your expected labels, and then cross-reference the results with your production verifier's behavior on the same inputs. The goal is to find misalignment: cases where the deception pattern is correctly identified here but mishandled downstream. After analysis, discard the prompt from any production path. Its value is in the gap analysis it enables, not in ongoing use.

The following template is designed to classify a single input claim into one or more deliberate deception patterns: paltering, false implication, category error, or motte-and-bailey. It instructs the model to output structured JSON with the detected pattern label, a concise rationale, and a confidence score. Replace each square-bracket placeholder with your own test data, output schema requirements, and operational constraints before running the prompt in your verification pipeline.

textCopy
You are a deception pattern classifier for a fact-checking verification pipeline. Your job is to analyze a single input claim and determine whether it exhibits one or more deliberate deception patterns. Do not fact-check the claim. Do not assess whether it is true or false. Only classify the rhetorical or logical structure.

Deception patterns to detect:
- **Paltering**: Using technically true statements to create a misleading impression.
- **False Implication**: Stating something true while implying something false without directly asserting it.
- **Category Error**: Assigning a property to something that cannot meaningfully possess that property, or conflating distinct categories.
- **Motte-and-Bailey**: Asserting a controversial, hard-to-defend claim (bailey) while retreating to a trivial, easy-to-defend claim (motte) when challenged.

Input claim:
[INPUT_CLAIM]

Additional context (optional):
[CONTEXT]

Output a single JSON object with this exact schema:
{
  "patterns": [
    {
      "label": "paltering | false_implication | category_error | motte_and_bailey | none",
      "rationale": "One-sentence explanation of why this pattern applies, referencing the specific language in the claim.",
      "confidence": 0.0-1.0
    }
  ],
  "primary_pattern": "The highest-confidence pattern label, or 'none' if no pattern detected.",
  "requires_human_review": true/false
}

Constraints:
[CONSTRAINTS]

Examples for calibration:
[EXAMPLES]

To adapt this template, start by replacing [INPUT_CLAIM] with a single assertion you want to test. The [CONTEXT] placeholder accepts optional surrounding text that may clarify the claim's intended meaning. Use [CONSTRAINTS] to add domain-specific rules, such as 'Do not flag standard legal hedging as paltering' or 'Treat all claims about future events as outside scope.' The [EXAMPLES] placeholder should contain 2-4 few-shot demonstrations showing correct classification decisions for your domain. If you are integrating this into a red-teaming harness, wire the requires_human_review field to your triage router so that ambiguous or multi-pattern claims receive manual inspection before entering production verification logic.

This prompt is designed as a batch classification tool within a broader adversarial testing pipeline, not as a standalone chat interface. The primary integration pattern is to run it against a curated dataset of known deception examples, capture structured outputs, and compare them against expected labels to measure the verification system's detection accuracy. The harness should treat the prompt as a stateless function: input claims go in, structured JSON classifications come out, and each call is independent to avoid session-drift effects that could corrupt test results.

For implementation, wrap the prompt in a scripted evaluation loop that reads from a test dataset (e.g., a CSV or JSONL file with claim and expected_pattern columns), sends each claim to the model with a low temperature setting (0.0–0.2) for deterministic outputs, and parses the JSON response. Validate the output schema immediately: check that pattern_label is one of the expected enum values (paltering, false_implication, category_error, motte_and_bailey, other), that detection_rationale is a non-empty string, and that confidence_score is a float between 0.0 and 1.0. Failed validations should trigger a single retry with the error message appended to the prompt as additional context. Log every raw response, validation failure, and retry attempt for post-run analysis. For high-stakes verification pipelines, route claims classified with confidence_score below 0.7 or pattern_label of other to a human review queue rather than auto-failing the test.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller models that may collapse multiple deception patterns into a single catch-all label or hallucinate pattern names outside the defined taxonomy. After each test run, compute per-pattern precision and recall against your ground-truth labels, and pay special attention to motte_and_bailey false negatives, which are the most common failure mode when the model confuses a defensible narrow claim with the broader implied claim. Store these metrics per model version and prompt version to detect regressions when either changes.