Internal Contradiction Flagging Prompt for AI-Generated Text

This prompt is designed for LLM application developers who need to measure output consistency as a quality metric. The primary job-to-be-done is automated detection of factual drift and logical conflicts within a single model response. You should use this prompt when you already have the final model output and want to verify that the text does not contradict itself—for example, stating a policy applies to all users in one paragraph and listing excluded groups in the next. It belongs in post-generation verification pipelines, not in retrieval or evidence-matching workflows. It assumes the text is self-contained and does not require cross-referencing external sources to identify conflicts.

The ideal user is an engineering lead or product manager building guardrails for a customer-facing AI feature. Required context includes the full model output text and a defined risk tolerance for contradiction severity. You should not use this prompt when the goal is to compare the output against a knowledge base (use an evidence-matching prompt), when checking for contradictions across multiple documents (use a cross-document contradiction prompt), or when the text is intentionally dialectical or presents multiple viewpoints. The prompt is also unsuitable for real-time streaming output, as it requires the complete response to analyze.

Before deploying this prompt, define what constitutes an actionable contradiction for your use case. A statement that 'shipping takes 3-5 days' and later 'delivery may take up to a week' is a soft inconsistency that may not warrant a flag, while 'we never share data with third parties' followed by 'our analytics partner processes your information' is a hard contradiction requiring immediate suppression or review. Wire the prompt into a post-processing step that can either block the output, route it for human review, or log the contradiction rate as a quality metric. Start by running this prompt on a golden dataset of known consistent and inconsistent outputs to calibrate your severity thresholds before enabling it in production.

This prompt template is designed to be pasted directly into your LLM system to flag self-contradictions within a single piece of AI-generated text. It instructs the model to act as a meticulous editor, scanning the provided content for statements that logically conflict with each other. The output is a structured JSON report that is immediately machine-readable, making it suitable for integration into automated evaluation pipelines, content quality gates, or human review queues. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can adapt it to your specific content and risk tolerance without modifying the core instruction set.

textCopy
You are a meticulous consistency auditor. Your task is to analyze the provided [CONTENT] and identify any internal contradictions. An internal contradiction occurs when two or more statements within the text cannot logically be true at the same time, or when a later statement directly conflicts with an earlier one.

For each contradiction you find, you must output a JSON object with the following structure:
{
  "contradictions": [
    {
      "id": "string (unique identifier, e.g., 'contra-1')",
      "severity": "string (one of: 'critical', 'major', 'minor')",
      "statement_a": {
        "excerpt": "string (the exact text of the first conflicting statement)",
        "location": "string (descriptor like 'paragraph 2, sentence 3')"
      },
      "statement_b": {
        "excerpt": "string (the exact text of the second conflicting statement)",
        "location": "string (descriptor like 'paragraph 5, sentence 1')"
      },
      "conflict_explanation": "string (a concise explanation of why these statements conflict)",
      "root_cause_hypothesis": "string (one of: 'tense_mismatch', 'numerical_error', 'definitional_shift', 'scope_change', 'negation_error', 'other')"
    }
  ],
  "overall_consistency_score": "number (a score from 0.0 to 1.0, where 1.0 is perfectly consistent)",
  "summary": "string (a brief, one-sentence summary of the findings)"
}

If no contradictions are found, return the JSON with an empty 'contradictions' array, an 'overall_consistency_score' of 1.0, and an appropriate 'summary'.

---

[CONTENT]:
"""
[INPUT_TEXT]
"""

[CONSTRAINTS]:
- Do not flag stylistic choices, rhetorical questions, or hypothetical scenarios as contradictions.
- A statement and its later clarification are not a contradiction unless the clarification directly negates the original fact.
- Focus strictly on factual, logical, and numerical consistency.
- If the [RISK_LEVEL] is 'high', you must be more sensitive to potential contradictions and flag borderline cases as 'minor'.

[RISK_LEVEL]: [LEVEL]

To adapt this template, replace the [INPUT_TEXT] placeholder with the full text you want to audit. The [LEVEL] placeholder should be set to either 'high' or 'standard' to control the sensitivity of the detection. For high-stakes applications like medical or legal document review, always use 'high' and route all flagged contradictions for mandatory human review. The output JSON schema is strict; you should implement a post-processing validation step in your application harness to ensure the model's response conforms to this structure before it's consumed by downstream systems. A common failure mode is the model generating a non-JSON preamble; your parser should be resilient to this by extracting the first valid JSON object it finds.

The internal contradiction flagging prompt is designed to operate as a post-generation quality gate within an LLM application pipeline. After your primary model produces long-form text—such as a report, article, summary, or analysis—you route that output through this prompt before it reaches the end user. The harness should treat the contradiction detector as a synchronous or near-synchronous validation step, not an offline batch job, because downstream actions (publishing, sending, storing) depend on the verdict. The prompt expects a single [INPUT] text block and returns a structured JSON payload containing contradiction flags, conflicting segment pairs, root cause hypotheses, and a severity score. Your application code must parse this JSON, check the contradictions_found boolean, and branch accordingly: pass clean outputs through, quarantine flagged outputs for review, or trigger a regeneration loop with the contradiction report fed back as context.

Validation and schema enforcement is the first integration concern. The prompt's [OUTPUT_SCHEMA] placeholder should be populated with a strict JSON schema that your application validates before acting on the result. Use a library like jsonschema (Python) or zod (TypeScript) to confirm that every contradiction object contains required fields: segment_a, segment_b, conflict_type, explanation, and severity. If the model returns malformed JSON—missing fields, wrong types, or unparseable syntax—do not silently proceed. Implement a retry loop with a repair prompt that feeds the raw output and validation errors back to the model, asking for a corrected JSON response. Cap retries at 2-3 attempts. If validation still fails, log the failure, flag the output for human review, and surface the raw model response in your observability dashboard. For high-stakes domains like healthcare or legal content, require human approval on any output where contradictions_found is true or where validation fails, regardless of severity score.

Model choice and latency budgeting shape how you deploy this prompt. The contradiction detection task requires strong reasoning and careful comparison, so prefer models with robust instruction-following and long-context handling: GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid small or fast models (e.g., GPT-3.5 Turbo, Claude Haiku) for production contradiction detection unless you've calibrated their performance on your specific content type and accept a higher false-negative rate. Expect 2-5 seconds of latency for inputs under 4,000 tokens; longer documents may require chunking with overlapping windows. If your application cannot tolerate this latency inline, consider an asynchronous architecture: queue the generated text, run contradiction detection in a background worker, and notify downstream systems or users when the check completes. For real-time chat applications, you may need to accept a trade-off where contradiction detection runs only on the final composed response rather than every streaming chunk.

Logging and observability are essential because contradiction detection is a quality metric you'll want to track over time. Log every invocation with: the input text hash, the model used, the full contradiction report, validation status, retry count, latency, and the final disposition (passed, flagged, regenerated). Emit metrics for contradiction rate by content type, severity distribution, validation failure rate, and retry frequency. This data feeds two critical workflows. First, eval integration: periodically run a golden dataset of texts with known contradictions through the prompt and compare model verdicts against ground truth, computing precision, recall, and F1 on contradiction detection. Use an LLM judge prompt from the contradiction detection eval rubric to grade explanation quality and severity calibration. Second, drift detection: if your contradiction rate suddenly spikes or drops, investigate whether a model update, prompt change, or content shift caused the change before users are affected.

Regeneration loops are the most advanced integration pattern and carry the highest risk of unintended behavior. When a contradiction is flagged, you can feed the contradiction report back to the original generation model with instructions to resolve the conflicts and produce a consistent version. This requires careful prompt engineering: include the original text, the contradiction report, and explicit instructions to fix only the identified conflicts without introducing new ones. After regeneration, run contradiction detection again on the revised output. Set a hard limit of 2 regeneration attempts to prevent infinite loops. If contradictions persist after two rounds, quarantine the output and escalate to a human reviewer with the full contradiction trail. Never silently suppress contradiction flags to meet a latency SLA—the whole point of this harness is to prevent inconsistent outputs from reaching users.

Tool integration is minimal for this prompt because contradiction detection is a self-contained reasoning task. The prompt does not need RAG retrieval, API calls, or database lookups at runtime—all evidence must already be present in the input text. However, you may want to integrate source reliability metadata into the prompt's [CONTEXT] placeholder. If your system tracks source authority scores, recency, or corroboration counts, include that structured metadata alongside each source segment. The model can use it to weight conflicting claims and produce better root cause hypotheses. Do not rely on the model to fetch or compute source reliability at runtime; provide it as pre-computed context. For batch processing of large document corpora, wrap this prompt in a queue system with configurable concurrency, cost tracking per invocation, and dead-letter queues for documents that fail validation after all retries are exhausted.