Batch Document Claim Inventory Prompt

This prompt is for platform engineers and AI pipeline builders who need to extract a complete inventory of factual claims from a batch of documents, not just a single file. The goal is a consolidated, deduplicated, and provenance-tracked output where every claim can be traced back to its source document and location. Use this when downstream verification, evidence matching, or audit workflows require a unified view of all assertions across a document collection. This is not for single-document extraction or for generating answers from claims; it is a batch ingestion and normalization step.

The ideal user is operating a claim extraction pipeline at scale—processing dozens or hundreds of documents through a verification system. They need claims that are atomic, self-contained, and carry complete provenance metadata (document ID, paragraph index, character offset, and author context). The prompt expects a batch of documents as input, each with a unique identifier and full text. It produces a single consolidated claim inventory with cross-document deduplication, meaning semantically equivalent claims appearing in multiple documents are merged into one claim with multiple source references. This consolidation step is critical for controlling downstream evidence-matching costs and avoiding redundant verification work.

Do not use this prompt when you only need to extract claims from a single document—the deduplication and consolidation logic adds unnecessary complexity and token cost for single-document workflows. Do not use it when you need claims annotated with verification verdicts or evidence matches; this prompt only extracts and inventories claims, leaving verification to downstream steps. Do not use it when your documents contain primarily opinions, predictions, or subjective content without factual assertions—the prompt will produce sparse or empty inventories. For regulated or high-risk domains (legal, medical, financial), always route the output through human review before using claims in automated decision systems, and ensure your provenance tracking is precise enough to support audit requirements.

This template is designed for platform engineers who need to process multiple documents through a claim extraction pipeline and produce a single, deduplicated inventory where every claim is traceable back to its source document, section, and position. Unlike single-document extraction prompts, this template handles cross-document consistency checks, batch boundary artifacts, and consolidated output formatting. Replace each square-bracket placeholder with your actual inputs before sending to the model.

textCopy
You are a claim extraction system processing a batch of documents. Your task is to produce a consolidated claim inventory with document-level provenance.

## INPUT DOCUMENTS
[DOCUMENTS]

## EXTRACTION RULES
1. Extract every discrete, self-contained factual assertion from each document.
2. Each claim must be atomic: one verifiable statement per claim.
3. Preserve the original wording where possible. If you must normalize, note the change.
4. Assign each claim a unique ID in the format: [DOC_ID]-CLAIM-[NNN]
5. For each claim, record:
   - The claim text
   - Source document identifier
   - Section or paragraph reference
   - Character offset range (approximate if exact is unavailable)
   - Whether the claim is a direct quote, paraphrase, or original assertion
   - Any hedging language or uncertainty markers present

## CROSS-DOCUMENT RULES
- If the same claim appears in multiple documents, list it once and include all source references.
- If two documents make contradictory claims, flag both with a CONTRADICTION marker and list the conflicting claim IDs.
- If a claim in one document is partially supported or elaborated by another, note the relationship without merging distinct claims.

## OUTPUT FORMAT
Return a JSON object with this structure:
{
  "inventory_metadata": {
    "total_documents_processed": int,
    "total_claims_extracted": int,
    "deduplicated_claim_count": int,
    "contradiction_count": int,
    "extraction_timestamp": "ISO 8601"
  },
  "claims": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "claim_type": "factual|opinion|hedged|numerical|causal|quotation",
      "sources": [
        {
          "document_id": "string",
          "section": "string",
          "offset_start": int,
          "offset_end": int,
          "attribution_type": "direct_quote|paraphrase|original"
        }
      ],
      "hedging_detected": boolean,
      "hedging_terms": ["string"],
      "contradicts": ["claim_id"],
      "supported_by": ["claim_id"],
      "extraction_confidence": 0.0-1.0
    }
  ],
  "contradictions": [
    {
      "claim_id_a": "string",
      "claim_id_b": "string",
      "contradiction_type": "direct|temporal|numerical|logical",
      "description": "string"
    }
  ],
  "batch_boundary_notes": ["string"]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adapt this template by adjusting the claim type taxonomy to match your domain. For legal documents, add claim types like obligation, right, condition_precedent. For financial documents, add projection, historical_figure, methodology_assertion. The cross-document contradiction detection is the most expensive part of this prompt; if your batch size is large, consider running single-document extraction first, then using a separate deduplication and contradiction detection pass. Always validate the output JSON against your expected schema before ingestion, and route any claims with extraction_confidence below your threshold to human review.

The batch document claim inventory prompt is designed to run as a map-reduce or fan-out operation across document collections. Each document gets its own prompt invocation with the document text and metadata injected into the [DOCUMENTS] placeholder. The prompt returns a structured claim inventory per document, and the harness layer is responsible for merging these per-document inventories into a consolidated output while detecting cross-document claim conflicts, duplicates, and batch boundary artifacts. Do not feed all documents into a single prompt call unless the total token count is well within the model's context window and you have verified that claim provenance tracking remains accurate at scale. For collections larger than 10-15 documents, use a document-level fan-out pattern with a downstream merge step.

The harness should enforce a strict JSON output schema on every invocation. Configure your model call with response_format set to json_schema (OpenAI) or equivalent structured output mode, and validate the returned JSON against the expected schema before accepting it into the consolidated inventory. Key fields to validate include: claim_id uniqueness within each document batch, source_document_id matching the input document identifier, claim_text non-emptiness, and claim_type enum membership. If validation fails, implement a retry loop with the same prompt but append the validation error message to the [CONSTRAINTS] section. Cap retries at 3 attempts per document, then route failures to a dead-letter queue for human review. Log every validation failure with the document ID, error details, and retry count for observability.

Cross-document consistency checks belong in the post-merge harness layer, not inside the prompt. After collecting all per-document claim inventories, run a deduplication pass using semantic similarity thresholds on claim_text fields. Claims with cosine similarity above 0.92 (using an embedding model of your choice) should be flagged as potential duplicates and linked via a related_claim_ids array. For contradictory claims across documents—same subject, conflicting predicates—generate a contradiction_group record with both claim IDs and the conflicting text spans. These groups should be surfaced in the final inventory's cross_document_artifacts section rather than silently resolved. The harness should never auto-resolve contradictions; it should flag them for downstream human or programmatic review.

Batch boundary artifacts are a known failure mode when documents are processed independently. Claims that depend on context from a preceding or following document in the collection will be missed or malformed. To mitigate this, include a [NEIGHBOR_CONTEXT] placeholder in the prompt template that optionally receives a summary of adjacent documents when processing ordered collections (e.g., chronological reports, email threads, paginated filings). The harness should populate this field with a 2-3 sentence summary of the preceding and following document when document order is semantically meaningful. If document order is arbitrary, leave the field empty and note in the inventory metadata that cross-document context was not provided.

Model choice matters for this workload. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are suitable starting points. Avoid smaller or older models that struggle with consistent JSON schema adherence across long documents. For cost-sensitive pipelines processing hundreds of documents, consider a two-tier routing pattern: use a faster model (GPT-4o-mini, Claude Haiku) for initial claim extraction, then route documents where validation fails or where the claim count exceeds a threshold to a more capable model for re-extraction. Track per-document claim counts as a quality signal; sudden drops or spikes relative to document length often indicate extraction failures.

Finally, build eval checks into the harness before shipping. For each document batch, sample 5-10% of extracted claims and verify that the claim text is faithfully grounded in the source document—no hallucinated details, no dropped qualifiers, no merged claims from different sections. Use a separate LLM-as-judge prompt for this verification step, not the extraction prompt itself. Track precision (are extracted claims actually present in the source?) and recall (are obvious claims being missed?) over time. If recall drops below 85% or precision below 90%, pause the pipeline and investigate the prompt, model version, or document type distribution before continuing.