Unsupported Statement Audit Trail Generation Prompt Template

This prompt is designed for compliance officers, governance teams, and verification pipeline architects who need a machine-readable, human-reviewable audit trail explaining why a specific claim was classified as UNSUPPORTED. It is not a detection prompt; it is a post-classification documentation tool. Use it after your detection prompt has flagged a claim as lacking sufficient evidence. The primary job-to-be-done is to create an immutable, structured record that can be stored in a verification log, attached to a compliance packet, or surfaced during an external audit. The output must serve downstream traceability, not conversational disclosure to end users.

The ideal user is building or operating an automated fact-checking system where every verification decision must be defensible. Required context includes the original claim text, the evidence search history (queries executed and sources retrieved), the final classification verdict, and any reviewer notes. Do not use this prompt for real-time, user-facing explanations; its output is verbose, structured, and designed for internal systems of record. It is also inappropriate for claims that were successfully verified or contradicted—this prompt is specifically scoped to the UNSUPPORTED state, where the absence of evidence is the critical finding.

Before wiring this into your pipeline, ensure you have a reliable upstream detection step that correctly distinguishes UNSUPPORTED from CONTRADICTED and VERIFIED. A common failure mode is generating audit trails for claims that were simply misclassified due to a retrieval failure. The audit trail will faithfully document a broken process if the input classification is wrong. Always validate the upstream verdict before invoking this prompt, and consider adding a human review step for high-severity unsupported claims before the audit record is finalized and stored.

This template generates a structured, audit-ready record explaining why a specific claim was marked as unsupported. It captures the evidence search history, the decision rationale, and the reviewer context required for compliance and governance teams. The output is designed to be stored as an immutable record in your verification log, providing traceability from claim to verdict.

textCopy
You are an audit trail generator for a fact-checking pipeline. Your task is to produce a structured record explaining why a claim was marked UNSUPPORTED. Do not re-evaluate the claim. Document the process that led to the unsupported verdict.

## CLAIM
[CLAIM_TEXT]

## CLAIM ID
[CLAIM_ID]

## VERIFICATION CONTEXT
- Source Document: [SOURCE_DOCUMENT_REFERENCE]
- Extraction Timestamp: [EXTRACTION_TIMESTAMP]
- Pipeline Stage: [PIPELINE_STAGE]

## EVIDENCE SEARCH HISTORY
[EVIDENCE_SEARCH_LOG]

## VERDICT
UNSUPPORTED

## CONSTRAINTS
- Do not invent evidence or sources not present in the search history.
- If the search history is empty or incomplete, state that explicitly.
- Use precise language: distinguish between 'no evidence found' and 'evidence is insufficient.'
- Do not speculate on why evidence is missing.

## OUTPUT SCHEMA
Return a single JSON object with the following fields:
{
  "audit_record_id": "string, unique identifier for this audit entry",
  "claim_id": "string, the provided claim ID",
  "verdict": "UNSUPPORTED",
  "decision_rationale": "string, a concise explanation of why the claim is unsupported based on the evidence search history",
  "evidence_search_summary": {
    "sources_consulted": ["string, list of sources searched"],
    "queries_executed": ["string, list of search queries used"],
    "total_results_reviewed": "number",
    "relevant_results_found": "number",
    "search_timestamp_start": "ISO 8601 string",
    "search_timestamp_end": "ISO 8601 string"
  },
  "evidence_gap_description": "string, specific description of what evidence would be needed to verify this claim",
  "reviewer_context": {
    "pipeline_version": "string",
    "model_version": "string",
    "reviewer_notes": "string or null, any additional context for human reviewers"
  },
  "compliance_checks": {
    "evidence_exhaustion_declared": "boolean, was the search formally declared complete?",
    "human_review_required": "boolean, does this claim require human review?",
    "policy_version_applied": "string, version of the verification policy used"
  },
  "generated_at": "ISO 8601 timestamp"
}

To adapt this template, replace each square-bracket placeholder with live data from your pipeline. The [EVIDENCE_SEARCH_LOG] should contain the raw output of your retrieval system, including queries, sources, and timestamps. If your system uses a structured evidence store, serialize it into the log field. For high-compliance environments, ensure the compliance_checks block is populated by a separate policy engine, not by the model's own judgment. After generation, validate the JSON schema, confirm that no sources were invented by cross-referencing the sources_consulted list against your actual search index, and append the record to your immutable audit log before any human review step.

The audit trail prompt is a high-stakes component in a compliance pipeline. Its output is not a user-facing answer but a machine-readable record that must be stored, indexed, and potentially reviewed by auditors. The implementation harness must therefore treat the prompt as a record producer, not a conversational agent. The primary integration points are: a claim intake queue, a verification evidence store, the prompt execution service, a structured output validator, a retry/recovery layer, and an audit log database. Each claim that enters the pipeline should carry a unique claim_id and a verification_run_id to ensure every audit trail record is traceable back to its originating workflow.

The harness should enforce a strict validate-then-store contract. After the model returns a response, the first step is schema validation against the expected JSON output shape. Use a JSON Schema validator to confirm the presence and types of required fields: claim_id, verdict, evidence_search_summary, decision_rationale, reviewer_context, and traceability_metadata. If validation fails, do not store a partial record. Instead, route the failure to a retry queue with the original prompt, the validation error message, and a retry_count. Implement a maximum of 3 retries with exponential backoff. If all retries are exhausted, log the failure to a dead-letter queue and create a manual review ticket with the full prompt context and raw model output attached. This prevents silent data loss in the audit trail.

For storage, write each validated audit trail record as an immutable append-only entry in a dedicated audit_trail table or collection. The record should include the full prompt template used, the model version, the timestamp, and the validated output. Never update an audit trail record in place. If a claim is re-verified later, create a new record with a new verification_run_id and a reference to the previous record. This preserves the full decision history. Additionally, the harness should emit a structured log event for every verification attempt, including successful validations, retries, and dead-letter escalations, so that operations teams can monitor pipeline health and audit trail completeness in real time.

Model choice matters for this workflow. Use a model with strong instruction-following and structured output capabilities, such as gpt-4o or claude-3.5-sonnet, and set temperature=0 to maximize determinism. The prompt template includes a [RISK_LEVEL] parameter; when this is set to high, the harness should automatically flag the output for mandatory human review before the audit trail record is finalized. In this case, the record is written with a status: pending_review and a notification is sent to the designated review queue. Only after a human reviewer approves the record does its status change to final. This gating mechanism ensures that high-risk unsupported claims receive appropriate oversight without blocking the entire pipeline.

Finally, integrate the audit trail generation step into your broader verification workflow orchestration. The prompt should fire after evidence retrieval and sufficiency scoring are complete, and only when the claim has been classified as UNSUPPORTED. Do not generate audit trails for VERIFIED or CONTRADICTED claims unless your compliance policy explicitly requires it, as this will bloat storage and create noise. Use the traceability_metadata field to include the evidence search query history, the list of sources consulted, and the timestamp of the evidence exhaustion declaration. This ensures the audit trail is a self-contained record that an auditor can review without accessing external systems.