Factual Conflict Highlighting Prompt for Editors

This prompt is designed for editorial and fact-checking workflows where a human reviewer needs to quickly identify and assess contradictory passages within a single document or across a small set of provided sources. The ideal user is an editor, researcher, or analyst who is responsible for the final accuracy of a piece but is bottlenecked by the manual effort of cross-referencing statements. The required context is the full text of the document(s) to be reviewed. The prompt transforms this raw text into an annotated review packet, marking conflicting statements inline, adding margin notes, and packaging a structured context summary for the reviewer. Use this when the goal is to accelerate human review, not to make a final automated determination of truth.

This prompt is not a replacement for a human fact-checker and should not be used in fully automated pipelines where a contradiction flag triggers an automatic action, such as deleting content or issuing a public correction. It is a precision-recall tunable tool for highlighting likely conflicts before a human makes the final call. It is also not suitable for real-time contradiction detection in high-volume streaming data, as it is designed for a focused, document-level review. For that, consider a batched contradiction detection harness with a structured JSON output contract. The prompt is most effective on long-form, non-fiction content like research reports, investigative articles, legal filings, and technical documentation, where internal consistency is paramount.

Before using this prompt, ensure you have a clear policy for how a human reviewer should resolve a flagged conflict. The prompt's output is a starting point for investigation, not a verdict. A common failure mode is deploying this prompt without a downstream Standard Operating Procedure (SOP), leading to a backlog of flagged but unresolved contradictions. The next step after reading this section is to review the prompt template and adapt its [CONSTRAINTS] and [OUTPUT_SCHEMA] to match your specific editorial policy and the format of your review environment.

The prompt below is designed to be pasted directly into your model's system or user message. It instructs the model to act as an editorial assistant that highlights factual conflicts within a provided document. The template uses square-bracket placeholders for all dynamic inputs, such as the source text, the evidence set to compare against, and the desired output density. Replace each placeholder with your specific data before execution. This prompt is the core instruction set for a single-pass conflict highlighting task; it does not handle multi-turn refinement or evidence retrieval, which should be managed by your application harness.

textCopy
You are an editorial fact-checking assistant. Your task is to read the provided [DOCUMENT] and compare its factual claims against the [EVIDENCE_SET]. Identify every statement in the document that directly contradicts, partially mismatches, or is temporally inconsistent with the evidence.

For each conflict found, you must produce an annotation in the following structured format:
- CONFLICT_ID: A unique identifier (e.g., C-001).
- DOCUMENT_EXCERPT: The exact conflicting text from the document.
- EVIDENCE_EXCERPT: The specific text from the evidence that contradicts it.
- CONFLICT_TYPE: One of [DIRECT_CONTRADICTION, PARTIAL_MISMATCH, TEMPORAL_INCONSISTENCY, NUMERICAL_DISAGREEMENT].
- SEVERITY: A rating of [HIGH, MEDIUM, LOW] based on the [SEVERITY_RUBRIC].
- REVIEWER_NOTE: A concise explanation of the conflict, written for a human editor.

[DOCUMENT]:
[INPUT_TEXT]

[EVIDENCE_SET]:
[EVIDENCE_TEXT]

[SEVERITY_RUBRIC]:
- HIGH: The conflict involves a core factual error that changes the meaning or could cause harm.
- MEDIUM: The conflict involves a secondary detail that is incorrect but does not change the main point.
- LOW: The conflict is a minor phrasing mismatch, date ambiguity, or typo-level discrepancy.

[CONSTRAINTS]:
- Do not flag stylistic differences or paraphrasing as conflicts.
- If no evidence exists for a claim, do not flag it as a contradiction. Only flag claims where the evidence actively disagrees.
- Limit the total number of annotations to a maximum of [MAX_HIGHLIGHTS]. Prioritize HIGH severity conflicts first.
- Output only the structured annotations, with no additional commentary before or after.

To adapt this template, start by defining your [EVIDENCE_SET]. This could be a single trusted document, a concatenation of multiple sources, or the output of a retrieval step. The quality of the highlighting depends entirely on the relevance and completeness of this evidence. Next, calibrate the [SEVERITY_RUBRIC] to match your editorial team's definition of impact. A financial report will have a different rubric than a celebrity news article. Finally, tune [MAX_HIGHLIGHTS] to control precision-recall trade-offs. A low number forces the model to surface only the most critical issues, reducing noise for reviewers. After pasting the prompt, always run it against a golden set of documents with known conflicts to validate that your rubric and constraints produce the expected highlight density and accuracy before deploying to your editorial workflow.

The Factual Conflict Highlighting Prompt is designed to sit inside a document review pipeline, not as a standalone chat interaction. The typical integration pattern involves: (1) ingesting a source document, (2) splitting it into manageable chunks if it exceeds the model's context window, (3) running the prompt against each chunk or against paired chunks, (4) collecting inline conflict markers and margin notes, (5) validating the output schema, and (6) routing flagged passages to a human review queue. This harness must handle variable document lengths, enforce a consistent output contract, and avoid flooding reviewers with low-precision highlights.

Start by defining a strict output schema that the prompt must follow—typically a JSON array of conflict objects, each containing passage_a, passage_b, conflict_type (direct contradiction, temporal inconsistency, numerical disagreement, logical conflict), severity (high, medium, low), explanation, and source_location (section, paragraph index, or character offset). Implement a schema validator in your application layer that rejects malformed responses and triggers a retry. Use a model with strong instruction-following and JSON mode support (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). For long documents, implement a sliding window or section-by-section approach: compare each section against every other section for cross-document contradictions, and run a self-contradiction pass within each section. Deduplicate overlapping findings by clustering conflicts on passage proximity and keeping the highest-severity instance. Log every prompt invocation with input hash, output, latency, and validation status for debugging and audit trails.

The most important production control is precision-recall tuning. The prompt includes a [HIGHLIGHT_DENSITY] parameter (low, medium, high) that controls how aggressively the model flags potential conflicts. At 'low' density, the model should only flag clear, material contradictions; at 'high' density, it surfaces borderline cases for human judgment. Wire this parameter to a user-facing control or an A/B test framework. Implement a human review interface that displays the original passages side-by-side with the model's conflict markers and explanation, and captures reviewer verdicts (confirmed, false positive, needs more context). Feed these verdicts back into an eval dataset for regression testing. Never auto-publish or auto-correct based on conflict highlights without human approval—this is a high-risk editorial workflow where incorrect conflict flags can damage credibility. Set a maximum highlight budget per document (e.g., 20 conflicts) to prevent reviewer fatigue, and if the model exceeds it, re-run with lower density or escalate the document for a full manual review.