Cross-Format Batch Verification Orchestration Prompt

This prompt is designed for platform engineers and AI pipeline architects who need to process large, mixed-format claim sets through a verification workflow. The core job-to-be-done is generating a cost-aware, latency-budgeted execution plan that routes individual claims to the correct format-specific verification sub-prompt (e.g., sending a chart claim to a chart-to-data reconciliation prompt, not a text-only fact-checker). You should use this prompt when a single batch contains claims originating from text, tables, images, audio transcripts, or video, and manual routing is not scalable. The ideal user has a library of pre-tested verification sub-prompts and needs an orchestrator to assign work, manage dependencies, and aggregate results.

Do not use this prompt for single-claim verification or for batches where all claims share the same format. It is over-engineered for those cases. This prompt is also not a substitute for the verification sub-prompts themselves; it assumes those exist and are reliable. The orchestrator's value is in the plan, not in performing the verification. Before using this prompt, you must have a clear map of your available verification tools or sub-prompts, their cost profiles, and their expected latencies. The prompt requires these as input to produce a realistic plan. Without them, the model will generate a generic, non-executable outline that will fail in production.

The primary risk is that the orchestration plan looks plausible but contains subtle routing errors, such as sending a claim about a chart's trend line to a text-only contradiction detector. This leads to silent failures where claims are 'verified' against the wrong evidence modality. To mitigate this, you must validate the output plan against a schema that enforces format-to-sub-prompt mapping rules. A second risk is cost overrun: the model may produce a plan that exceeds your budget or latency SLA. The prompt template includes explicit [CONSTRAINTS] for cost and latency, but you should also implement a post-generation validator that simulates the plan's resource consumption before execution. For high-stakes verification (legal, financial, clinical), always route the final aggregated report for human review, as cross-format evidence correlation can produce false confidence when sources appear to agree but are actually describing different events.

This prompt template is the central instruction set for an orchestrator model that receives a batch of claims spanning multiple formats—text, tables, charts, images, audio transcripts, video segments—and produces a structured verification plan. The plan assigns each claim to a format-appropriate sub-prompt, orders verification steps so that dependencies resolve before dependent checks run, and specifies how partial results should be aggregated into a final batch output. The template uses square-bracket placeholders for all variable inputs so you can drop it into a pipeline without rewriting the core logic.

textCopy
You are a verification orchestrator. Your job is to produce a verification plan for a batch of claims that span multiple formats.

## INPUTS
- CLAIM_BATCH: [CLAIM_BATCH]
- AVAILABLE_VERIFIERS: [AVAILABLE_VERIFIERS]
- EVIDENCE_STORE_SCHEMA: [EVIDENCE_STORE_SCHEMA]
- CONSTRAINTS: [CONSTRAINTS]
- OUTPUT_SCHEMA: [OUTPUT_SCHEMA]

## TASK
1. Parse CLAIM_BATCH into individual claims. Preserve the original claim text, source format, and any provided metadata.
2. For each claim, determine the verification strategy:
   - Identify the claim's format type (text, table, chart, image, audio_transcript, video_segment, screenshot, infographic, diagram, slide_deck, rendered_report).
   - Map the claim to the most appropriate verifier from AVAILABLE_VERIFIERS. Use format-aware routing: a claim originating from a chart should route to a chart-aware verifier, not a generic text verifier.
   - If a claim requires evidence from a different format than its origin, flag it as cross-format and note the evidence format needed.
3. Build a dependency graph:
   - Claims that depend on the output of another verification step (e.g., a claim about a chart's trend direction depends on first extracting the underlying data) must be ordered after their dependencies.
   - Claims that can be verified independently should be marked for parallel execution.
   - Identify any claims that require human review before automated verification can proceed (e.g., OCR-ambiguous claims, disputed source authority).
4. Assign priority scores to each claim based on CONSTRAINTS. If a latency budget or cost cap is provided, sort claims so that high-priority claims complete first and low-priority claims can be dropped if the budget is exhausted.
5. Produce an aggregation strategy:
   - Specify how partial results from format-specific verifiers should be combined into a unified batch output.
   - Define conflict resolution rules when two verifiers disagree on the same claim.
   - Define handling for claims that cannot be verified (missing evidence, format incompatibility, verifier failure).

## CONSTRAINTS
- Total latency budget: [LATENCY_BUDGET_MS]
- Maximum cost budget: [COST_BUDGET]
- Minimum confidence threshold for auto-verdict: [MIN_CONFIDENCE]
- Claims below threshold must route to human review.
- Do not fabricate evidence. If evidence is missing, mark the claim as UNVERIFIABLE with a reason.
- For cross-format claims, include a note explaining why the evidence format differs from the claim format.

## OUTPUT_SCHEMA
Return a JSON object conforming to [OUTPUT_SCHEMA]. The schema must include:
- verification_plan: an ordered list of verification steps with claim IDs, assigned verifiers, dependency IDs, and priority scores.
- dependency_graph: a mapping of claim IDs to their prerequisite claim IDs.
- cross_format_flags: a list of claims requiring cross-format evidence with format-pair annotations.
- human_review_queue: claims routed to human review with reasons and packaged context.
- aggregation_rules: instructions for combining partial results, resolving conflicts, and handling unverifiable claims.
- budget_estimate: projected latency and cost for the plan.

## RISK_LEVEL
[RISK_LEVEL]

If RISK_LEVEL is HIGH, add a step that validates the verification plan itself before execution and require human approval of the plan.

To adapt this template, replace each square-bracket placeholder with your pipeline's actual values. [CLAIM_BATCH] should contain the raw claims in your internal format—JSON lines, a structured array, or a normalized claim object with claim_text, source_format, and metadata fields. [AVAILABLE_VERIFIERS] is a catalog of your format-specific verification prompts, each with a name, accepted input formats, evidence format requirements, and estimated latency. [EVIDENCE_STORE_SCHEMA] describes how your evidence store is organized so the orchestrator can reason about evidence availability without executing retrieval. [CONSTRAINTS] should include your latency budget in milliseconds, cost cap, and minimum confidence threshold. [OUTPUT_SCHEMA] is your desired JSON schema for the verification plan—define this strictly so downstream executors can parse the plan without ambiguity. [RISK_LEVEL] accepts LOW, MEDIUM, or HIGH and gates whether plan-validation and human-approval steps are injected.

Before deploying, test this prompt against pipeline-failure recovery scenarios: what happens when a verifier times out, when evidence is missing for a cross-format claim, or when two verifiers produce conflicting verdicts. The aggregation rules section of the output must handle these cases explicitly. Also validate that the dependency graph contains no cycles and that parallel execution groups do not share dependencies. If your use case involves regulated content, keep RISK_LEVEL at HIGH and ensure the human-approval gate is enforced in your application layer, not just described in the plan output.

This prompt is not a standalone call—it is the orchestration layer that sits between your claim ingestion queue and your format-specific verification workers. The harness must accept a batch of mixed-format claims (text assertions, table-derived numbers, chart-extracted statements, audio transcript segments, video scene descriptions) and return a structured verification plan. The plan assigns each claim to a format-appropriate sub-prompt, orders dependencies (e.g., 'verify OCR extraction before checking quote fidelity'), and applies cost and latency budgets. Wire this as a pre-processing step before dispatching work to individual verification prompts like Text-Claim-to-Table-Evidence or Audio-Transcript-Claim-to-Document-Evidence.

Input contract: The harness should supply [CLAIM_BATCH] as a JSON array of claim objects, each with claim_id, claim_text, source_format (enum: text, table, chart, image, audio_transcript, video_segment, screenshot, infographic, diagram, slide_deck), source_reference (pointer to original content), and optional priority and evidence_format_hints. Include [AVAILABLE_VERIFIERS] as a mapping of format-to-verifier-prompt IDs with estimated cost and latency per call. Include [BUDGET_CONSTRAINTS] with max_total_cost, max_latency_ms, and max_parallel_workers. The prompt returns a verification_plan object with ordered task_groups, each containing task_id, claim_ids, assigned_verifier, dependency_task_ids, estimated_cost, and aggregation_notes.

Validation layer: Before dispatching, validate the orchestration output against a strict schema. Check that every claim_id from the input appears exactly once in the plan. Verify no circular dependencies in dependency_task_ids. Confirm total estimated cost does not exceed max_total_cost. Reject plans that assign a verifier not present in [AVAILABLE_VERIFIERS]. If validation fails, retry the orchestration prompt with the validation errors appended to [CONSTRAINTS] as previous_plan_errors. After three failed retries, fall back to a simple round-robin assignment and log the escalation. Model choice: Use a model with strong structured-output and planning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set response_format to json_schema with the verification plan schema to avoid parsing failures. Logging: Record the full orchestration plan, validation results, retry count, and final dispatched tasks. This trace is essential for debugging cost overruns, dependency stalls, and format-routing errors in production.

Partial-result handling: When a dependency task fails or times out, the harness must decide whether to skip dependent tasks, run them with degraded evidence, or escalate for human review. Implement a dependency_failure_policy parameter (values: skip_dependents, run_with_partial_evidence, escalate) and pass it in [CONSTRAINTS]. The orchestration prompt should include this policy in its planning logic. Human review integration: For claims flagged with [RISK_LEVEL] = high or where the orchestration prompt assigns review_required: true, route the claim-evidence pair to a human review queue before final aggregation. The harness should package the claim, assigned verifier output, and dependency chain context into a structured handoff object compatible with the Multimodal Human-Review Handoff Packet Assembly Prompt.

What to avoid: Do not use this prompt for single-format batches—a dedicated verifier prompt is cheaper and simpler. Do not skip dependency validation; a circular dependency will stall your pipeline silently. Do not ignore the cost and latency budgets in production; the orchestration prompt can produce valid plans that exceed your limits if constraints are not enforced in the harness. Start with small batches (5–15 claims) to tune the planning behavior before scaling to hundreds of claims. If the orchestration prompt consistently over-assigns to expensive verifiers, add a cost_weight parameter to [CONSTRAINTS] and re-test against a golden set of claim batches with known optimal routing.