Claim-by-Claim Verification Ledger Prompt

This prompt is designed for auditors, compliance engineers, and verification pipeline operators who need to produce an immutable-style, claim-by-claim verification ledger. The core job is to transform a set of extracted claims and their corresponding evidence assessments into a structured, sequentially indexed record where each entry is self-contained, traceable, and resistant to tampering. You should use this prompt when the downstream consumer is a formal audit process, a regulatory submission, or an internal governance review that demands a clear chain of custody for every factual determination. It is not a general-purpose summarization tool or a replacement for a database; it is a structured record-generation step that sits at the end of a fact-checking pipeline, after claims have been extracted and evidence has been matched.

The ideal input for this prompt is a batch of pre-verified claims, each already paired with its supporting or contradicting evidence, a confidence score, and a preliminary verdict. The prompt expects you to provide these as structured data, typically as a JSON array of claim objects. It will then produce a ledger where each entry includes immutable fields such as a sequential index, a content hash of the claim and evidence, a timestamp, and the verification outcome. This structure enables later integrity checks: if any claim or evidence record is altered, the hash will break, making tampering evident. The prompt also includes optional fields for digital signatures or blockchain anchoring if your governance framework requires them, but the core value is the deterministic, hash-chained structure.

Do not use this prompt for real-time, conversational fact-checking or for generating narrative reports. It is purpose-built for structured, batch-oriented ledger generation. It also should not be used as the primary fact-checking engine; it assumes the verification logic has already been applied upstream. If you feed it unverified claims or raw, unpaired evidence, the output will be a well-formatted but meaningless ledger. Before implementing this prompt, ensure your pipeline can produce clean claim-evidence pairs with explicit verdicts. For high-stakes audit contexts, always pair this prompt's output with a human review step and an integrity validation check that recomputes hashes and confirms sequential index continuity before the ledger is finalized.

This section provides the core prompt for the Claim-by-Claim Verification Ledger. It is designed to be copied directly into your prompt library or orchestration code. The template uses square-bracket placeholders for all dynamic inputs, allowing you to inject claims, evidence, source metadata, and output constraints at runtime. The goal is a structured, append-only style record where each claim gets a unique, traceable entry suitable for audit and compliance review.

textCopy
You are an audit-grade verification ledger generator. Your task is to produce a strict, machine-readable ledger entry for each claim provided.

For each claim in [CLAIMS_LIST], generate a single ledger entry. The entire output must be a valid JSON array of objects, with one object per claim, conforming to [OUTPUT_SCHEMA].

## Input Data
- Claims: [CLAIMS_LIST]
- Evidence Pool: [EVIDENCE_POOL]
- Source Authority Registry: [SOURCE_REGISTRY]
- Verification Rules: [VERIFICATION_RULES]
- Ledger Start Index: [START_INDEX]

## Output Schema
Each ledger entry must contain these immutable fields:
- `entry_index`: A strictly sequential integer, starting from [START_INDEX].
- `claim_id`: A unique, deterministic hash (simulate with a consistent string format, e.g., CLAIM-XXXX) derived from the claim text.
- `claim_text`: The original claim text, verbatim.
- `verification_status`: One of `VERIFIED_TRUE`, `VERIFIED_FALSE`, `UNVERIFIABLE`, `DISPUTED`.
- `evidence_references`: An array of evidence IDs from the [EVIDENCE_POOL] that were used.
- `verdict_rationale`: A concise explanation of the verdict, referencing specific evidence.
- `confidence_score`: A float between 0.0 and 1.0.
- `review_required`: A boolean flag, `true` if confidence is below [CONFIDENCE_THRESHOLD] or status is `DISPUTED`.
- `previous_entry_hash`: A simulated hash of the previous entry's JSON string (use null for the first entry).
- `entry_hash`: A simulated hash of the current entry's JSON string (excluding this field itself).

## Constraints
- Do not alter the original claim text.
- If no evidence in the pool is relevant, set status to `UNVERIFIABLE` and evidence_references to an empty array.
- If evidence conflicts, set status to `DISPUTED` and explain the conflict in the rationale.
- The `entry_hash` must change if any other field in the entry changes.
- Output ONLY the JSON array. No introductory text, no markdown fences.

To adapt this template, replace the placeholders with your application's data structures. [CLAIMS_LIST] should be an array of pre-extracted claim strings. [EVIDENCE_POOL] is a dictionary mapping evidence IDs to their content and source metadata. [SOURCE_REGISTRY] provides authority scores for each source. [VERIFICATION_RULES] can include domain-specific logic, such as requiring two corroborating sources for a VERIFIED_TRUE status. The [CONFIDENCE_THRESHOLD] is a critical business rule that determines which entries are flagged for human review. After generating the ledger, always run a validation script to check for sequential index integrity, hash consistency, and schema compliance before storing the record.

The Claim-by-Claim Verification Ledger Prompt is designed to be the final, immutable record-keeping stage in a verification pipeline, not a standalone chat interaction. It expects structured input—pre-extracted claims, matched evidence, and preliminary verdicts—from upstream extraction and evidence-matching prompts. Wiring this prompt into an application means treating it as a stateless ledger writer: the application layer is responsible for assembling the input payload, assigning sequential claim IDs, generating content hashes, and storing the returned ledger entries in an append-only datastore. Do not rely on the model to generate its own sequential indices or hash references from scratch; provide them as part of [INPUT] to ensure determinism and auditability.

Validation and retry logic is critical because a malformed ledger entry breaks downstream audit integrity. After each model response, validate that every entry contains all required immutable fields (claim_id, claim_text, verdict, confidence, evidence_summary, source_references, ledger_entry_hash, previous_entry_hash, timestamp). If validation fails, retry with the same input and an explicit repair instruction appended to the prompt: 'The previous output was missing required fields. Return a complete ledger entry with all fields populated.' Set a maximum of two retries before flagging the entry for human review. For high-risk domains such as financial audit or healthcare compliance, route any entry where verdict is UNVERIFIED or confidence falls below a configurable threshold (e.g., 0.7) to a human review queue before the ledger entry is finalized.

Model choice and tool integration should favor models with strong structured-output discipline and low hallucination rates on factual summarization tasks. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable starting points. Enable structured output mode (JSON mode or function-calling with a strict schema) rather than relying on free-text parsing. If your pipeline uses retrieval-augmented generation (RAG) upstream, pass the retrieved evidence snippets directly into the [EVIDENCE] placeholder rather than asking the model to recall facts from training data. For production deployments, log every prompt version, model version, input payload, raw response, validation result, and final ledger entry to an immutable audit log. This traceability is essential for governance reviews and debugging verification discrepancies. Avoid using this prompt for real-time, user-facing chat; it is a batch-processing component designed for throughput, consistency, and audit-readiness.