Quote Verification Batch Processing Prompt

This prompt is designed for platform engineers and verification pipeline operators who need to verify attributed quotes against source material at scale. The job-to-be-done is a high-throughput, structured comparison of many quote-source pairs, producing both per-item verification results and aggregate quality metrics in a single, cost-effective batch operation. The ideal user is someone integrating this step into an automated content verification system, a CMS publishing pipeline, or a post-hoc editorial audit workflow. They are less concerned with the nuances of a single quote and more focused on system-level throughput, cost control, and partial-failure recovery.

Use this prompt only when you have already completed the preceding pipeline stages: quote extraction and source material retrieval. This prompt does not perform those functions. It assumes a clean, pre-assembled batch of objects, each containing an attributed quote and the corresponding source text. The prompt is optimized for scale, so it expects a list of items as input and returns a list of structured verification results. Do not use this prompt for single-quote ad-hoc checks; the overhead of the batch structure and aggregate metrics makes it inefficient for that purpose. For individual verification tasks, use the Quote-to-Source Comparison Prompt Template instead.

Before invoking this prompt, ensure your input batch is well-formed and that you have a clear strategy for handling partial failures. The prompt's instructions include guidance for the model to return results for all items, even if some cannot be fully verified, rather than failing the entire batch. Your application harness should be prepared to parse a response that may contain a mix of successful verifications and items flagged with an abstained status. The next step after receiving the output is to route high-confidence matches for automated action, flag discrepancies for human review, and log the aggregate metrics for pipeline monitoring.

This prompt template is designed for platform engineers running quote verification at scale across document collections. It accepts a batch of quote-source pairs, processes each one independently, and returns structured per-quote verification results alongside aggregate quality metrics. The template uses square-bracket placeholders for all variable inputs, constraints, and output schema definitions. Replace each placeholder with your actual values before sending the prompt to the model. The template assumes you have already extracted quotes and retrieved candidate source material; it does not perform extraction or retrieval itself.

textCopy
You are a quote verification system processing a batch of attributed quotes against their claimed source material. Your task is to compare each quote to its source and produce structured verification results.

## INPUT
[BATCH_INPUT]

Each item in the batch contains:
- quote_id: unique identifier for this quote
- attributed_quote: the exact text of the attributed quote
- attributed_speaker: the person or entity the quote is attributed to
- source_text: the original source material to compare against
- source_metadata: date, publication, URL, or other provenance information

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "batch_id": "[BATCH_ID]",
  "processed_at": "ISO timestamp",
  "results": [
    {
      "quote_id": "string",
      "verification_status": "EXACT_MATCH | CLOSE_MATCH | PARAPHRASE | MISQUOTATION | NOT_FOUND | FABRICATED | INCONCLUSIVE",
      "fidelity_score": 0.0-1.0,
      "matched_excerpt": "exact source text that matches, or null",
      "discrepancies": [
        {
          "type": "WORD_SUBSTITUTION | OMISSION | ADDITION | REORDERING | CONTEXT_STRIPPING | MEANING_DISTORTION",
          "description": "specific description of the discrepancy",
          "severity": "LOW | MEDIUM | HIGH | CRITICAL"
        }
      ],
      "context_notes": "any relevant surrounding context from the source that affects interpretation",
      "confidence": 0.0-1.0,
      "requires_human_review": true/false,
      "review_reason": "explanation if human review is needed, or null"
    }
  ],
  "aggregate_metrics": {
    "total_quotes": integer,
    "exact_matches": integer,
    "close_matches": integer,
    "paraphrases": integer,
    "misquotations": integer,
    "not_found": integer,
    "fabricated": integer,
    "inconclusive": integer,
    "average_fidelity_score": 0.0-1.0,
    "human_review_rate": 0.0-1.0
  },
  "processing_notes": ["any batch-level observations about data quality, edge cases, or systemic issues"]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Process each quote independently. Do not let one quote's result influence another.
2. For EXACT_MATCH: the quote appears verbatim in the source.
3. For CLOSE_MATCH: minor differences exist (punctuation, capitalization, filler words) but meaning is preserved.
4. For PARAPHRASE: wording differs but the speaker's intended meaning is preserved.
5. For MISQUOTATION: wording differences change or distort the meaning.
6. For NOT_FOUND: the quote's content cannot be located in the source material.
7. For FABRICATED: indicators suggest the quote was invented (no provenance, stylistic mismatch, anachronisms).
8. For INCONCLUSIVE: insufficient evidence to determine status with confidence.
9. Set requires_human_review to true for any CRITICAL severity discrepancy, FABRICATED status, or confidence below [CONFIDENCE_THRESHOLD].
10. If the source_text is empty, missing, or clearly unrelated to the quote, mark as INCONCLUSIVE with confidence 0.0 and set requires_human_review to true.
11. Do not hallucinate source content. Only reference text actually present in the provided source_text field.
12. If the batch contains more than [MAX_BATCH_SIZE] items, return an error object instead of partial results.

To adapt this template for your pipeline, replace the square-bracket placeholders with concrete values. [BATCH_INPUT] should contain your serialized quote-source pairs, typically as a JSON array. [BATCH_ID] should be a unique identifier for traceability across your verification pipeline. [CONSTRAINTS] should specify any domain-specific rules, such as tolerance for minor punctuation differences in legal contexts or strict verbatim requirements for academic citations. [EXAMPLES] should include at least three few-shot examples covering different verification statuses, especially the boundary between CLOSE_MATCH and MISQUOTATION where your organization's tolerance for wording differences matters most. [CONFIDENCE_THRESHOLD] should be a float between 0.0 and 1.0 that determines when results route to human review. [MAX_BATCH_SIZE] should reflect your model's context window and your latency budget. After replacing placeholders, validate that the output schema matches your downstream ingestion contract before deploying to production. For high-stakes verification workflows, always route items with requires_human_review: true to a review queue and log the full verification result for audit purposes.

The batch processing prompt is designed to be called from an application orchestration layer, not used as a standalone chat interface. Your application is responsible for splitting the input document collection into batches that respect the model's context window and rate limits, assembling each batch request with the prompt template, collecting responses, and merging results into a unified output. The prompt itself expects a structured input containing an array of quote-source pairs and returns a structured JSON output with per-quote verification results and aggregate metrics. The application layer must validate that the output schema matches the expected contract before accepting results, because partial failures and malformed JSON are common at scale.

Implement a batch processor with these components: (1) Input splitter that divides the quote collection into batches of [MAX_ITEMS_PER_BATCH] items, respecting the model's context limit minus prompt overhead. (2) Rate-limit handler that tracks tokens-per-minute and requests-per-minute against the model provider's limits, inserting exponential-backoff waits when limits are approached. (3) Retry wrapper that catches HTTP errors, timeout errors, and JSON parse failures, retrying up to [MAX_RETRIES] times with jitter before marking a batch as failed. (4) Partial-failure recovery that saves successfully processed items from failed batches and re-queues only the unprocessed items into a new batch. (5) Output validator that checks each response against the expected JSON schema, flagging missing required fields, invalid enum values, and confidence scores outside the 0-1 range. (6) Result aggregator that merges per-batch results into a single output, recalculating aggregate metrics across all batches rather than trusting per-batch aggregates. Log every batch attempt, retry, validation failure, and aggregate metric to your observability platform for debugging and cost tracking.

For high-risk verification workflows where quote integrity failures carry legal, reputational, or compliance consequences, add a human review routing layer after aggregation. Route any quote with a confidence score below [REVIEW_THRESHOLD], any quote flagged with a severity level of 'high' or 'critical', and any batch that failed after all retries. Package the review context as a structured handoff containing the original quote, the source material, the model's verification output, and the specific concern that triggered review. Do not auto-publish or auto-accept verification results below the threshold. For cost and latency monitoring, track tokens consumed per batch, wall-clock time per batch, and total cost per document collection. Use these metrics to tune batch size, model choice, and retry strategy. Start with smaller batches and conservative rate limits, then increase after observing production behavior for at least [OBSERVATION_PERIOD].

Model selection matters for batch verification. Choose a model with strong instruction-following and structured output capabilities for schema compliance. If using a model that does not support native JSON mode, add a post-processing step that extracts JSON from markdown fences or repairs common formatting errors before validation. For very large document collections, consider a two-tier architecture: a fast, cheaper model for initial screening that flags likely issues, and a more capable model for detailed verification of flagged items only. This reduces cost while maintaining accuracy on the subset that matters most. Always version your prompt template and track which version produced each batch result in your logs, so you can attribute accuracy changes to prompt changes versus model behavior drift.

Before deploying to production, run the harness against a golden test set of quote-source pairs with known verification outcomes. Measure schema compliance rate, accuracy against ground truth, and the distribution of confidence scores. Set your review threshold based on the precision-recall trade-off observed in testing, not an arbitrary number. After deployment, continuously sample production outputs for human review to detect drift, and feed confirmed errors back into your test set. The batch processing prompt is a component in a larger system; the harness is what makes it reliable, auditable, and safe to operate at scale.