Fallacy Detection in Chain-of-Thought Prompt

This prompt is built for evaluation pipelines that need to screen reasoning traces for logical fallacies before the reasoning is used to make decisions or generate final answers. The ideal user is an AI engineer or evaluation lead deploying reasoning models where the path matters as much as the conclusion. You have a chain-of-thought trace—from a reasoning model, an agent, or a RAG system—and you need to know whether it contains circular reasoning, false dilemmas, hasty generalizations, post-hoc errors, or other logical flaws. This judge prompt audits reasoning that already exists; it does not generate new reasoning.

Use this prompt when you need automated fallacy detection with step-level citations and severity ratings. It fits into evaluation harnesses that run after reasoning generation but before the reasoning is shown to users, fed into downstream tools, or used to justify high-stakes decisions. The prompt expects a complete reasoning trace as input and returns structured JSON with fallacy classifications, the specific steps where each fallacy occurs, severity ratings, and brief explanations. This output can feed into regression test suites, CI/CD gates, or human review queues. Do not use this prompt for real-time user-facing chat, for grading final answers without reasoning traces, or as a substitute for domain-expert review in regulated workflows.

Before wiring this into production, define your severity thresholds and decide what happens when a fallacy is detected. In low-risk workflows, you might log the finding and continue. In high-risk domains—clinical, legal, financial—you should route flagged traces to human review and block automated action until the review is complete. Pair this prompt with a schema validator to catch malformed JSON output, and consider running it against a golden dataset of known fallacious and valid reasoning traces to calibrate your acceptance criteria before deployment.

This prompt template is designed to be dropped directly into your evaluation harness. It instructs the model to act as a logical fallacy auditor, scanning a provided reasoning trace for common fallacies such as circular reasoning, false dilemmas, hasty generalizations, and post-hoc errors. The template uses square-bracket placeholders for all dynamic inputs, allowing you to swap in different reasoning traces, adjust the list of target fallacies, and modify the output schema without rewriting the core instruction set. Before pasting, ensure you have a clear reasoning trace to evaluate and have defined your desired output format.

textCopy
You are a logical fallacy detection auditor. Your task is to analyze the provided chain-of-thought reasoning trace and identify any logical fallacies present. For each fallacy found, you must provide a step-level citation, a severity rating, and a brief explanation.

### INPUT
[REASONING_TRACE]

### TARGET FALLACIES
Focus your analysis on the following fallacy types, but flag any others you detect under "Other":
[FALLACY_LIST]

### OUTPUT SCHEMA
Return your findings as a single JSON object conforming to this schema:
{
  "fallacies": [
    {
      "fallacy_type": "string (e.g., 'Circular Reasoning', 'False Dilemma')",
      "step_index": "integer (the 1-based index of the reasoning step containing the fallacy)",
      "step_text": "string (the exact text of the offending step)",
      "severity": "string (one of: 'Low', 'Medium', 'High', 'Critical')",
      "explanation": "string (a concise explanation of why this step is fallacious and how it impacts the overall argument)"
    }
  ],
  "overall_assessment": "string (a summary of the reasoning trace's logical soundness, noting if any conclusions are unsupported due to fallacies)"
}

### CONSTRAINTS
- Only report a fallacy if you are highly confident it is present. Do not over-flag.
- If no fallacies are found, return an empty 'fallacies' array and a positive overall_assessment.
- The 'step_index' must correspond to the step numbering in the provided [REASONING_TRACE].
- The 'severity' rating should reflect the impact on the argument's conclusion: 'Critical' means the conclusion is directly invalidated, 'Low' means a minor rhetorical flaw.

To adapt this template, start by replacing [REASONING_TRACE] with the full text of the chain-of-thought output you want to audit. Next, curate the [FALLACY_LIST] to match your specific evaluation rubric; you might include only formal fallacies for a logic course or a broader set for general content moderation. The [OUTPUT_SCHEMA] is provided as a strict JSON contract, which is critical for automated pipelines. If your application requires a different structure, modify the schema description but keep the instructions precise to prevent the model from drifting into unstructured commentary. For high-stakes evaluations, always route outputs where severity is 'High' or 'Critical' for human review before taking any automated action based on the fallacy report.

The fallacy detection prompt is designed to operate as a screening step inside an automated evaluation pipeline, not as a standalone chat interaction. It expects a complete reasoning trace as input and returns structured fallacy classifications with step-level citations. The primary integration point is after a reasoning model produces its chain-of-thought and before that trace is scored for correctness, coherence, or faithfulness. By inserting fallacy detection early in the pipeline, you can flag traces that contain circular reasoning, false dilemmas, hasty generalizations, or post-hoc errors before they corrupt downstream eval metrics or reach end users.

Validation and retry logic is critical because the prompt's output must conform to a strict schema for automated processing. Implement a JSON schema validator that checks for required fields (fallacy_type, step_index, severity, explanation), enum adherence for fallacy_type and severity, and array integrity for the detected_fallacies list. If validation fails, retry the prompt once with the original input and a brief error message appended to [CONSTRAINTS] indicating which field was malformed. If the second attempt also fails, log the raw output and escalate to a human review queue rather than silently dropping the trace. For high-stakes domains like healthcare, legal, or finance, configure the pipeline to require human sign-off on any trace with a severity rating of high or critical, regardless of validation success.

Model choice and cost optimization should match the risk profile of the evaluation task. For development and pre-release regression testing, a fast, cost-effective model like GPT-4o-mini or Claude Haiku is usually sufficient for fallacy detection. For production monitoring of safety-critical reasoning traces, use a more capable judge model such as GPT-4o, Claude Sonnet, or an equivalent to reduce false negatives. Log every evaluation with the prompt version, model identifier, input trace hash, fallacy output, validation status, and reviewer decision. This audit trail is essential for debugging judge drift, calibrating severity thresholds, and defending evaluation results during compliance reviews. Avoid wiring fallacy detection directly into user-facing blocking flows without a human-in-the-loop override for edge cases where the judge model may misclassify legitimate reasoning patterns as fallacies.