Research Paper Fact-Interpretation Split Prompt

This prompt is designed for scientific claim verification pipelines that must extract checkable assertions from academic papers. It separates verifiable factual statements from author interpretation, methodological choices, speculative discussion, and rhetorical framing. Use it when downstream fact-checking accuracy depends on clean claim boundaries and when mixing results with discussion-section language would cause over-confident verification outputs. This prompt belongs in the pre-processing stage of a verification workflow, before evidence matching or claim scoring. It assumes the input is a full paper section or abstract, not a single sentence.

The ideal user is a verification pipeline engineer or an AI builder constructing a system that ingests scientific literature and produces structured, evidence-backed claim records. The required context includes the full text of the target section, a defined output schema for fact and interpretation objects, and a clear taxonomy of what constitutes a verifiable fact in the target domain (e.g., measured values, reported sample sizes, statistical results). The prompt is most effective when paired with a downstream evidence-matching step that can independently query databases or knowledge bases against the extracted fact statements. Do not use this prompt for news articles, legal briefs, or financial reports; those domains require different classification taxonomies and boundary rules.

Before deploying this prompt, validate its performance against a golden dataset of annotated papers where fact-interpretation boundaries are known. Common failure modes include misclassifying methodological choices as facts, treating speculative hedging as interpretation when a factual core exists, and splitting multi-clause sentences in ways that lose context. Always route low-confidence outputs to human review, especially when the separation confidence score falls below a defined threshold. The next step after extraction should be to pass the fact statements to an evidence-matching prompt, while interpretation passages can be routed to a separate synthesis or summarization workflow.

This prompt template is designed to be pasted directly into your application's model call. It instructs the model to decompose a research paper excerpt into two distinct lists: verifiable factual claims and author interpretation. The prompt uses a strict JSON output schema so you can parse the results programmatically, route facts to an evidence-matching engine, and flag interpretations for human review or downstream analysis. Replace every square-bracket placeholder with actual values before sending the request.

textCopy
You are an expert scientific claim auditor. Your task is to read a research paper excerpt and separate verifiable factual statements from author interpretation, methodological choices, speculative discussion, and rhetorical framing.

## INPUT
[RESEARCH_PAPER_EXCERPT]

## OUTPUT SCHEMA
Return a single JSON object with exactly two keys: "verifiable_facts" and "interpretation".

- "verifiable_facts": An array of objects, each with:
  - "claim_id": A unique string identifier (e.g., "F1", "F2").
  - "statement": The atomic, self-contained factual claim as a single sentence.
  - "source_span": The verbatim text from the input that supports this claim.
  - "checkable_by": One of ["external_reference", "reproducible_experiment", "internal_data", "logical_proof"].
  - "section_origin": The paper section where this claim appears (e.g., "Results", "Methods").
- "interpretation": An array of objects, each with:
  - "passage_id": A unique string identifier (e.g., "I1", "I2").
  - "statement": The interpretive, analytical, or speculative passage.
  - "source_span": The verbatim text from the input.
  - "type": One of ["author_interpretation", "methodological_choice", "speculation", "rhetorical_framing", "opinion"].
  - "section_origin": The paper section where this passage appears.

## CONSTRAINTS
1. Do not omit any factual claim or interpretive passage present in the input.
2. If a sentence contains both a fact and an interpretation, extract the fact into "verifiable_facts" and the interpretation into "interpretation" using overlapping source spans if necessary.
3. A "verifiable_fact" must be a statement whose truth can be checked independently of the authors' opinion. Reported measurements, statistical results, and described observations are facts. Statements about what those results "suggest," "imply," or "demonstrate" are interpretation.
4. Distinguish "Results" section content (facts) from "Discussion" section content (interpretation) when section origin is clear.
5. Flag overclaimed findings: if an interpretation passage asserts a causal relationship or generalizes beyond the study's design, set "type" to "speculation" and note the overclaim in the statement.
6. If the input contains no verifiable facts, return an empty array for "verifiable_facts". If it contains no interpretation, return an empty array for "interpretation".

## EXAMPLES
Input: "The mean response time was 245ms (SD=15ms). This suggests the new interface is faster than the baseline."
Output:
{
  "verifiable_facts": [
    {
      "claim_id": "F1",
      "statement": "The mean response time was 245ms with a standard deviation of 15ms.",
      "source_span": "The mean response time was 245ms (SD=15ms).",
      "checkable_by": "reproducible_experiment",
      "section_origin": "Results"
    }
  ],
  "interpretation": [
    {
      "passage_id": "I1",
      "statement": "The authors interpret the 245ms response time as evidence that the new interface is faster than the baseline.",
      "source_span": "This suggests the new interface is faster than the baseline.",
      "type": "author_interpretation",
      "section_origin": "Discussion"
    }
  ]
}

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high", you must also include a "confidence" field (0.0 to 1.0) for every fact and interpretation, and flag any claim where confidence is below 0.7 for human review.

After pasting this template, replace [RESEARCH_PAPER_EXCERPT] with the text you want to analyze. Set [RISK_LEVEL] to "high" when the output feeds into a compliance, clinical, or publication-critical workflow—this activates the confidence scoring and human-review flags. For lower-stakes batch processing, set it to "standard" to reduce token usage. The output JSON can be validated against the schema before ingestion; reject any response where claim_id values are not unique or where source_span text does not appear verbatim in the input. For production pipelines, combine this prompt with a retry-and-repair harness that detects missing keys or malformed JSON and re-prompts the model with the error message.

This prompt is designed as a pre-processing step in a scientific claim verification pipeline. It should be called before evidence retrieval and matching, because downstream accuracy depends on cleanly separating checkable factual assertions from author interpretation, methodological commentary, and speculative discussion. The typical integration point is immediately after paper ingestion and text extraction, producing structured output that feeds into a claim extraction and decomposition stage. Do not use this prompt as a standalone fact-checker—it classifies and separates, but does not verify claims against external sources.

Wire the prompt into an application by constructing a request that includes the full paper text as [PAPER_TEXT], an optional [DOMAIN] field to bias classification toward domain-specific terminology (e.g., 'biomedical', 'materials science', 'computational linguistics'), and a strict [OUTPUT_SCHEMA] defining the expected JSON structure with fields for section_id, passage_text, classification (one of fact, interpretation, methodology, speculation, rhetorical_framing), confidence (0.0–1.0), and rationale. Validate the output against this schema immediately. If the model returns malformed JSON, use a repair prompt with the original output and schema definition before retrying. For high-stakes verification workflows, route any passage classified with confidence below 0.7 to a human review queue with the original text, model classification, and rationale attached. Log every classification decision with a trace ID linking paper, section, passage, and model version for auditability.

Choose a model with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all perform well on this classification task, but test across your target domain's paper types before committing. If processing long papers, chunk by section rather than by arbitrary token windows—section boundaries are natural fact-interpretation boundaries, and splitting mid-section degrades classification quality. Implement a retry strategy with exponential backoff for transient API failures, but cap retries at three attempts. If the model consistently produces low-confidence classifications across multiple sections, escalate to a human reviewer rather than looping indefinitely. For batch processing, queue papers through a state machine that tracks extraction → classification → validation → routing, with dead-letter queues for unprocessable documents. Avoid wiring this prompt directly into a synchronous user-facing flow; the classification step should be asynchronous to accommodate validation, repair, and human review without blocking the user.