Logical Conflict Extraction Prompt Within a Single Document

This prompt is designed for editors, reviewers, and verification pipeline developers who need to detect internal logical contradictions within a single document. It is not for cross-document comparison, numerical disagreement detection, or temporal inconsistency checking. Use this when a long-form report, article, manuscript, or AI-generated output must be audited for statements that cannot all be true simultaneously. The prompt produces a structured self-contradiction report with conflicting statement pairs, logical dependency chains explaining why the statements conflict, severity ratings, and explicit false-positive filtering for rhetorical devices, conditional statements, and narrative framing that may appear contradictory but are not. This belongs in editorial QA workflows, compliance review pipelines, and AI output validation harnesses where internal consistency is a quality gate before publication or downstream consumption.

Before wiring this into a production pipeline, define the minimum severity threshold for flagging a contradiction. A character's eye color changing mid-narrative is a low-severity factual drift; a report claiming a drug is both safe and unsafe in the same section is a high-severity material conflict. The prompt's severity field uses a rubric that considers factual materiality, downstream consequence, and correction urgency. You should calibrate this rubric against your own editorial or compliance standards. For high-risk domains like healthcare or legal review, always route severity: critical findings to a human reviewer and never auto-resolve them. The prompt includes a false_positive_rationale field for each flagged pair, which is your primary defense against flagging rhetorical questions, hypotheticals, or character dialogue as genuine contradictions.

Do not use this prompt for comparing claims across multiple documents, detecting numerical disagreements with tolerance windows, or validating event timelines. Those tasks require pairwise comparison logic, unit normalization, or temporal reasoning that this single-document prompt is not designed for. If you need cross-document contradiction detection, use the Cross-Document Contradiction Detection Prompt Template instead. For AI-generated text specifically, pair this prompt with an eval harness that measures output consistency as a quality metric over time. Start by running it on a golden dataset of documents with known contradictions and false-positive traps to tune your severity thresholds before deploying to production.

This section provides the core prompt template for detecting internal inconsistencies within a single document. It is designed to be self-contained: copy the code block below into your LLM interface, replace the square-bracket placeholders with your actual document text and configuration, and run it. The prompt instructs the model to produce a structured self-contradiction report, including conflicting statement pairs, the logical dependency chain connecting them, and a severity rating. It also includes explicit filters to reduce false positives from rhetorical devices, hypotheticals, and conditional statements.

textCopy
You are an expert editor and logical analyst. Your task is to identify internal logical conflicts and self-contradictions within the provided [DOCUMENT]. A logical conflict occurs when two or more statements within the document cannot all be true simultaneously based on standard logical reasoning.

Follow these steps:
1. Parse the entire [DOCUMENT] to understand its core claims, arguments, and factual assertions.
2. Identify pairs of statements that are mutually exclusive or create a paradox.
3. For each conflict, trace the logical dependency chain. Explain *why* the statements conflict, referencing the specific text.
4. Classify the conflict type (e.g., Direct Contradiction, Temporal Inconsistency, Numerical Disagreement, Definitional Conflict).
5. Assign a severity rating based on the [SEVERITY_RUBRIC]:
   - **Critical:** Contradicts the central thesis or a primary factual claim, making the core argument unsound.
   - **High:** Contradicts a major supporting argument or a key piece of evidence.
   - **Medium:** Contradicts a minor point or a peripheral detail.
   - **Low:** A semantic inconsistency or a phrasing issue that does not impact factual accuracy.
6. Apply these false-positive filters before reporting a conflict:
   - **Rhetorical Devices:** Ignore statements that are clearly metaphorical, hyperbolic, or part of a rhetorical question.
   - **Conditional Statements:** Do not flag a conflict if one statement is explicitly conditional (e.g., "If X, then Y") and the other describes a different scenario.
   - **Temporal Evolution:** Do not flag a conflict if the document describes a legitimate change over time (e.g., "We started with 10 users" and "We now have 100 users").
   - **Hypotheticals:** Ignore statements within clearly marked hypothetical or speculative scenarios.

**Input Document:**
[DOCUMENT]

**Output Format:**
Return a valid JSON object with the following schema:
{
  "document_id": "[DOCUMENT_ID]",
  "contradictions": [
    {
      "conflict_id": "string",
      "statement_a": {
        "text": "exact quoted text from the document",
        "location": "section or paragraph identifier if available"
      },
      "statement_b": {
        "text": "exact quoted text from the document",
        "location": "section or paragraph identifier if available"
      },
      "logical_dependency_chain": "A step-by-step explanation of why these statements cannot both be true.",
      "conflict_type": "Direct Contradiction | Temporal Inconsistency | Numerical Disagreement | Definitional Conflict",
      "severity": "Critical | High | Medium | Low",
      "false_positive_check": "A brief note confirming the conflict is not a rhetorical device, conditional, temporal evolution, or hypothetical."
    }
  ],
  "analysis_summary": "A brief summary of the document's overall logical coherence."
}

If no conflicts are found, return the JSON with an empty 'contradictions' array and a positive analysis_summary.

To adapt this template, start by replacing the [DOCUMENT] placeholder with the full text you want to analyze. For long documents, consider breaking them into logical sections and running the prompt iteratively to stay within context window limits. The [SEVERITY_RUBRIC] is defined inline but can be customized; for instance, a legal team might redefine 'Critical' to mean 'contradicts a material clause.' The [DOCUMENT_ID] is a free-form field to help you track results back to your source system. The primary failure mode of this prompt is flagging stylistic or rhetorical contrasts as logical errors, which is why the false-positive filter step is mandatory. For high-stakes workflows like contract review or clinical documentation, you must add a human review step after extraction to validate each reported conflict before taking any action.

Integrating the logical conflict extraction prompt into an application requires treating it as a structured data producer, not a free-text assistant. The prompt is designed to output a JSON array of conflict objects, each containing statement_a, statement_b, conflict_type, logical_chain, severity, and false_positive_risk. Your harness must enforce this schema strictly. Begin by wrapping the prompt call in a function that accepts the document text and any runtime constraints (e.g., [SEVERITY_THRESHOLD], [MAX_CONFLICTS]). Use a model with strong JSON mode or structured output support—OpenAI's gpt-4o with response_format: { type: "json_object" } or equivalent—to minimize parsing failures. Before processing the response, validate it against a JSON Schema definition that requires all fields, enforces enum values for conflict_type (e.g., direct_contradiction, mutual_exclusion, temporal_impossibility, definitional_conflict), and constrains severity to a 1–5 integer range.

After schema validation, apply semantic quality checks before the output reaches downstream consumers. Implement a false-positive filter that re-examines conflict pairs where false_positive_risk is high or where conflict_type is direct_contradiction but the statements contain hedging language, conditionals, or rhetorical devices flagged in the prompt's own instructions. A secondary verification prompt can be called here: feed the original statement pair and the model's conflict explanation into a lightweight confirmation prompt that returns a verified, dismissed, or needs_review verdict. For high-severity conflicts (severity ≥ 4), route the output to a human review queue with the original document excerpts, the logical chain, and a pre-formatted review interface. Log every extraction run with a unique run_id, the document hash, model version, prompt version, and validation outcomes. This audit trail is essential for tuning false-positive rates and defending editorial decisions.

When wiring this into a larger verification pipeline, treat the conflict extractor as one stage in a directed acyclic graph. Its output should feed into a deduplication stage that merges overlapping conflict pairs (e.g., the same contradiction detected in different sections) and a prioritization stage that ranks conflicts by severity and downstream impact. Avoid calling the extraction prompt on documents larger than the model's effective context window without chunking. If chunking is required, implement overlap windows (e.g., 20% overlap between chunks) and a cross-chunk reconciliation step that merges conflicts spanning chunk boundaries. Set a retry policy: if JSON parsing fails, retry once with a stricter schema reminder in the system message. If validation fails on required fields, retry with the specific validation errors injected into the prompt. After two retries, log the failure and escalate to a human operator rather than silently dropping the document. The goal is a reliable, observable extraction stage that produces auditable conflict reports, not a black-box text generator.