Inconsistency Audit Prompt for Long-Form Reports

This prompt is designed for a specific, high-stakes job: systematically auditing a single long-form document to find internal contradictions before it reaches a critical audience. The ideal user is a compliance officer preparing a regulatory filing, an editorial team lead finalizing an annual report, or a verification engineer building an automated quality gate for published content. The core assumption is that you have the complete, final draft of a report—such as a financial disclosure, a clinical study, a legal brief, or a technical specification—and you need to ensure it does not contradict itself on facts, figures, dates, or logical conclusions. The prompt performs a structured, section-by-section comparison to produce traceable findings, not a vague summary, making each flagged issue directly actionable for a human reviewer.

You should use this prompt when the cost of an internal inconsistency is high and manual line-by-line comparison is too slow or error-prone. For example, a financial report stating a revenue figure of $4.2M in the executive summary and $3.9M in the detailed financials creates a material error that undermines credibility. Similarly, a clinical document that describes a treatment as 'contraindicated for patients under 18' in one section and 'safe for adolescent use' in another presents a safety risk. The prompt is built to catch these exact classes of errors—numerical disagreements, temporal impossibilities, direct logical conflicts, and definitional drift—and to cite the conflicting sections precisely so a human can resolve the discrepancy with full context.

Do not use this prompt as a general-purpose proofreader or grammar checker; it is not designed to catch spelling mistakes, stylistic inconsistencies, or formatting errors. It is also not a fact-checker against external ground truth—it only compares the document against itself. If you need to verify claims against a knowledge base or external sources, you should pair this prompt with a separate evidence-matching workflow from the Fact Checking pillar. Finally, avoid using this prompt on short documents (under a few pages) where a manual review is trivial, or on documents that are still in early draft stages with known incomplete sections, as the prompt will flag intentional placeholders and unresolved decisions as contradictions, generating noise that wastes reviewer time. For best results, run this audit on a content-complete, near-final draft as a pre-publication or pre-submission gate.

This prompt template is designed to be pasted directly into your prompt layer or AI harness. It accepts a long-form report and performs a systematic, section-by-section audit to identify internal contradictions, temporal inconsistencies, numerical disagreements, and logical conflicts. The template uses square-bracket placeholders that you must replace with your specific report content, audit parameters, and output format requirements before execution. The prompt is structured to force pairwise comparison logic and produce structured findings with precise section references, making it suitable for compliance, editorial, and quality assurance workflows where traceability is mandatory.

textCopy
You are an inconsistency audit system. Your task is to perform a systematic, section-by-section audit of the provided long-form report to identify internal contradictions, temporal inconsistencies, numerical disagreements, and logical conflicts.

## REPORT TO AUDIT
[REPORT_CONTENT]

## AUDIT SCOPE
- Sections to include: [SECTION_LIST or "all sections"]
- Comparison depth: [PAIRWISE_ALL | ADJACENT_ONLY | KEY_CLAIMS]
- Inconsistency categories to flag: [CONTRADICTION | TEMPORAL | NUMERICAL | LOGICAL | ALL]
- Minimum severity threshold: [LOW | MEDIUM | HIGH | CRITICAL]

## AUDIT METHOD
1. Extract all verifiable factual claims from each section, preserving original text and section identifiers.
2. Perform pairwise comparison of claims across the specified sections.
3. For each potential inconsistency, classify it into one of the requested categories.
4. Assign a severity rating based on: factual materiality, downstream consequence, and correction urgency.
5. For each finding, provide the conflicting statements with exact section references and quote the original text.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "audit_metadata": {
    "report_title": "string",
    "sections_audited": ["string"],
    "total_claims_extracted": number,
    "total_comparisons_performed": number,
    "findings_count": number
  },
  "findings": [
    {
      "finding_id": "string",
      "category": "CONTRADICTION | TEMPORAL | NUMERICAL | LOGICAL",
      "severity": "LOW | MEDIUM | HIGH | CRITICAL",
      "statement_a": {
        "section": "string",
        "paragraph": number or "string",
        "quoted_text": "string"
      },
      "statement_b": {
        "section": "string",
        "paragraph": number or "string",
        "quoted_text": "string"
      },
      "conflict_description": "string explaining the nature of the inconsistency",
      "resolution_recommendation": "string suggesting how to resolve the conflict",
      "requires_human_review": boolean
    }
  ],
  "coverage_summary": {
    "sections_without_findings": ["string"],
    "sections_with_findings": ["string"],
    "comparison_matrix_complete": boolean
  }
}

## CONSTRAINTS
- Only flag genuine inconsistencies. Do not flag rhetorical devices, conditional statements, or legitimate context shifts as contradictions.
- When the same fact is stated differently but not contradictorily, classify as consistent.
- For numerical claims, apply a tolerance window of [TOLERANCE_PERCENT or "5%"] before flagging.
- If a potential inconsistency is ambiguous, set requires_human_review to true and explain the ambiguity.
- Do not fabricate findings. If no inconsistencies exist, return an empty findings array with complete coverage_summary.
- Preserve exact quoting: do not paraphrase or alter the original text in quoted_text fields.

## EXAMPLES
[FEW_SHOT_EXAMPLES or "No examples provided. Proceed with the audit using the method described above."]

## RISK LEVEL
[RISK_LEVEL or "MEDIUM"] - [CUSTOM_RISK_NOTE or "Audit findings should be reviewed by a human before publication or regulatory submission."]

To adapt this template, replace the square-bracket placeholders with your specific values. For [REPORT_CONTENT], paste the full text of the report to be audited. For [SECTION_LIST], provide a comma-separated list of section identifiers if you want to limit the audit scope; otherwise use "all sections". Choose the comparison depth based on your thoroughness requirements: PAIRWISE_ALL compares every section against every other section (most thorough, highest token cost), ADJACENT_ONLY compares neighboring sections, and KEY_CLAIMS extracts only major claims for comparison. Set [TOLERANCE_PERCENT] to control numerical comparison sensitivity—5% is a reasonable default for most business reports. The [FEW_SHOT_EXAMPLES] placeholder can be populated with 2-3 example finding objects to calibrate the model's severity judgments and category classifications. For high-stakes audits in regulated domains, set [RISK_LEVEL] to HIGH and add a custom risk note about mandatory human review before any downstream action.

Before deploying this prompt into a production pipeline, validate the output against the JSON schema using a programmatic validator. Common failure modes include the model returning findings without exact quoted_text (paraphrasing instead), missing the coverage_summary when no findings exist, or misclassifying rhetorical questions as logical conflicts. Build a retry layer that catches schema validation errors and resubmits with explicit formatting reminders. For reports exceeding the model's context window, chunk the report into sections and run multiple audits, then merge findings with a deduplication pass. Always log the full prompt, response, and validation result for audit trail purposes, especially when findings trigger corrections in published documents.

The Inconsistency Audit Prompt is designed to be a single step in a larger document verification pipeline. It should not be called in isolation without upstream content preparation and downstream validation. Before invoking this prompt, the long-form report must be segmented into clearly labeled sections with stable identifiers. The prompt expects a structured input containing a report_title, a sections array where each object has a section_id and text, and an optional coverage_instructions field to specify which section pairs to compare. If your document is a raw PDF or DOCX, you must first run a layout-aware extraction step to produce this structured input. Do not pass raw binary data or unstructured markdown directly to this prompt.

The prompt returns a JSON object containing an audit_findings array. Each finding must include conflicting_sections (a list of section IDs), inconsistency_category (from a controlled vocabulary like direct_contradiction, numerical_disagreement, temporal_inconsistency, terminology_mismatch, logical_conflict), statement_a and statement_b (the exact conflicting text excerpts), explanation, and severity (e.g., critical, major, minor). A coverage_report object should also be returned, listing which section pairs were compared and which were skipped. To integrate this into an application, wrap the LLM call in a harness that: (1) validates the output JSON against this schema, (2) checks that all referenced section_id values exist in the input, (3) verifies that statement_a and statement_b are verbatim substrings of the source sections (or flags extraction errors if not), and (4) confirms the coverage_report matches the requested comparison scope. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_OUTPUT_ERRORS]. If the retry also fails, route the document to a human review queue with the partial results and error context.

For high-stakes compliance or editorial workflows, never auto-apply corrections based on this prompt's output. The correction_recommendation field in each finding is a suggestion for a human reviewer, not an executable edit. Log every audit run with the input document version, the full prompt payload, the raw model response, the validation results, and the reviewer's final disposition for each finding. This audit trail is essential for governance and for measuring the prompt's precision and recall over time. When choosing a model, prefer those with strong instruction-following and structured output capabilities. For reports exceeding the model's context window, implement a sliding window or hierarchical audit strategy: first audit within each major section, then audit across section clusters, and finally merge findings with deduplication logic. Avoid the temptation to skip the coverage report validation—it is your primary defense against silent failures where the model audits only the first few sections and ignores the rest.