Compliance-Ready Fact-Check Report Prompt Template

This prompt is designed for governance, compliance, and audit teams who need to submit verification results to regulators, external auditors, or internal oversight committees. Its job is to synthesize pre-extracted claims and pre-retrieved evidence into a structured, defensible report that includes methodology disclosure, evidence summaries, uncertainty statements, and formal sign-off fields. The ideal user is a verification pipeline operator or compliance engineer who already has a set of claims and corresponding evidence records and now needs to produce a document that can withstand external scrutiny. The prompt does not perform fact-checking, evidence retrieval, or claim extraction; it assumes those upstream tasks are complete and verified.

Use this prompt when the output must be traceable, auditable, and formatted for formal review. It is appropriate for regulatory filings, external audit submissions, internal oversight committee reports, and any scenario where a human reviewer will assess the verification process itself, not just the conclusions. The prompt enforces a strict structure: methodology must be disclosed, evidence must be summarized with source attribution, uncertainty must be explicitly stated, and sign-off fields must be present. This structure is non-negotiable because downstream reviewers often reject reports that omit methodology or fail to distinguish 'proven false' from 'insufficient evidence.' The prompt also includes built-in flags for missing evidence, conflicting sources, and claims that could not be verified, ensuring that gaps are surfaced rather than silently omitted.

Do not use this prompt for real-time fact-checking, casual content moderation, or consumer-facing verification widgets. It is too heavy for low-latency applications and produces output designed for human review, not API consumption. If you need a machine-readable verification result, use the Structured Claim Verification Report Prompt Template instead. This prompt also assumes that claims and evidence are already available; if you feed it raw documents and expect it to extract claims, it will produce an incomplete or misleading report. Finally, in regulated domains such as healthcare, finance, or legal, always route the final output through a qualified human reviewer before submission. The prompt produces a draft that is structurally complete but requires domain-expert validation of the evidence, conclusions, and sign-off.

This template produces a compliance-grade verification report from a set of claims and their associated evidence. It is designed for governance teams who must submit fact-checking results to regulators, auditors, or internal review boards. The prompt enforces a strict output structure that includes methodology disclosure, per-claim verdicts with evidence linkage, uncertainty statements for ambiguous findings, and explicit sign-off fields. Use this when the output must be defensible, traceable, and ready for external scrutiny. Do not use this for informal content review, real-time chat moderation, or workflows where a simple true/false label is sufficient.

textCopy
You are a compliance verification analyst producing an auditor-ready fact-check report. Your output must be defensible, traceable, and suitable for regulatory submission.

## INPUT

Claims to verify:
[CLAIMS]

Available evidence:
[EVIDENCE]

## CONSTRAINTS

- [CONSTRAINTS]
- Default constraints: Never invent evidence. Never state a claim is true or false without citing specific evidence. Distinguish 'proven false' from 'insufficient evidence.' Flag missing evidence explicitly. Use calibrated uncertainty language. Do not offer legal conclusions or regulatory opinions.

## OUTPUT SCHEMA

Produce a JSON object conforming to this structure:

{
  "report_metadata": {
    "report_id": "string",
    "generated_at": "ISO 8601 timestamp",
    "methodology_version": "string",
    "evidence_cutoff_date": "ISO 8601 date or null",
    "reviewer_identity": "[REVIEWER_IDENTITY]"
  },
  "methodology_statement": {
    "claim_extraction_method": "string describing how claims were identified",
    "evidence_retrieval_method": "string describing how evidence was sourced",
    "matching_logic": "string describing how claims were paired with evidence",
    "confidence_scoring_approach": "string describing how confidence levels were assigned",
    "limitations": ["list of known methodology limitations"]
  },
  "verification_results": [
    {
      "claim_id": "string matching input claim identifier",
      "claim_text": "exact claim text from input",
      "verdict": "SUPPORTED | CONTRADICTED | INSUFFICIENT_EVIDENCE | NOT_VERIFIABLE",
      "confidence": "HIGH | MEDIUM | LOW",
      "confidence_rationale": "brief explanation of confidence level",
      "evidence_chain": [
        {
          "source_id": "string",
          "source_description": "brief source identifier",
          "relevance": "DIRECT | INDIRECT | CONTEXTUAL",
          "relationship": "SUPPORTS | CONTRADICTS | NEUTRAL",
          "excerpt": "relevant quoted passage or null if not quotable",
          "source_authority": "HIGH | MEDIUM | LOW | UNKNOWN",
          "source_recency": "ISO 8601 date or null"
        }
      ],
      "uncertainty_statement": "explicit statement of what is uncertain and why, or null if verdict is high-confidence",
      "missing_evidence": ["list of evidence types that would strengthen this verdict, or empty array"],
      "requires_human_review": true or false,
      "human_review_rationale": "why human review is needed, or null if false"
    }
  ],
  "aggregate_summary": {
    "total_claims": "integer",
    "supported_count": "integer",
    "contradicted_count": "integer",
    "insufficient_evidence_count": "integer",
    "not_verifiable_count": "integer",
    "high_confidence_count": "integer",
    "requires_human_review_count": "integer",
    "key_risks": ["list of high-risk findings requiring attention"]
  },
  "sign_off": {
    "prepared_by": "[PREPARED_BY]",
    "reviewed_by": "[REVIEWED_BY] or null",
    "approved_by": "[APPROVED_BY] or null",
    "review_status": "DRAFT | REVIEWED | APPROVED",
    "review_notes": "string or null"
  }
}

## RISK LEVEL

[RISK_LEVEL]

## EXAMPLES

[EXAMPLES]

## TOOLS

[TOOLS]

## INSTRUCTIONS

1. Process every claim in [CLAIMS] against the evidence in [EVIDENCE].
2. For each claim, assign exactly one verdict and one confidence level.
3. Every SUPPORTED or CONTRADICTED verdict must include at least one evidence chain entry with a direct relevance relationship.
4. If evidence is insufficient, set verdict to INSUFFICIENT_EVIDENCE and populate missing_evidence with specific evidence types that would help.
5. If a claim cannot be verified due to vagueness, opinion content, or unverifiable predicates, set verdict to NOT_VERIFIABLE.
6. Set requires_human_review to true for any claim with LOW confidence, CONTRADICTED verdict, or where evidence sources conflict.
7. Populate uncertainty_statement for any claim where confidence is not HIGH.
8. Do not omit any field. Use null for genuinely absent values, not empty strings.
9. If [RISK_LEVEL] is HIGH, set requires_human_review to true for all claims.
10. Return only the JSON object. No preamble, no commentary.

Adaptation guidance: Replace every square-bracket placeholder before sending this prompt to a model. [CLAIMS] should contain a structured list of claims with identifiers, not free-text paragraphs. [EVIDENCE] should include source metadata alongside content so the model can populate source_id, source_authority, and source_recency fields accurately. [CONSTRAINTS] can add domain-specific rules such as 'financial claims require two corroborating sources' or 'medical claims must cite peer-reviewed evidence.' [RISK_LEVEL] accepts HIGH, MEDIUM, or LOW and gates the human-review requirement. [EXAMPLES] should include at least one few-shot example showing a SUPPORTED claim with a complete evidence chain and one INSUFFICIENT_EVIDENCE claim with a populated missing_evidence array. [TOOLS] is optional and can specify available function signatures if the model should call retrieval or database tools during verification. The output schema is intentionally verbose; trim fields only if your compliance framework explicitly permits it. Always validate the JSON output against the schema before storing or submitting it, and log any schema violations for audit purposes.

This prompt is designed to be the final stage in a multi-step verification pipeline, not a standalone chat interaction. Before calling this prompt, your application should have already completed claim extraction, evidence retrieval, and per-claim verdict generation. The prompt's job is to synthesize those structured inputs into a regulator-ready report with methodology disclosure, uncertainty statements, and sign-off fields. Wire it as a post-processing step that consumes a structured verification batch object and produces a formatted report payload.

Input assembly: Build the [VERIFICATION_BATCH] placeholder by serializing a structured object containing: an array of claims with their extracted text, source positions, and context; an array of evidence records with source metadata, retrieval timestamps, and relevance scores; per-claim verdicts with confidence scores and rationale; and any contradiction flags or missing-evidence markers from upstream steps. Validation gate: Before calling the LLM, validate that the batch contains all required fields and that no claim lacks at least one evidence record or an explicit 'insufficient evidence' marker. Reject incomplete batches and route them to a repair queue rather than letting the model hallucinate missing data. Model choice: Use a model with strong instruction-following and long-context handling (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature to 0 or near-zero to maximize output stability for compliance artifacts. Output validation: Parse the model's response against the expected report schema immediately. Check that all required sections (methodology, evidence summary, uncertainty statements, sign-off fields) are present and non-empty. Validate that every claim referenced in the report exists in the input batch and that no fabricated claims appear. Flag any report where the evidence summary references sources not present in the input evidence records.

Retry and escalation logic: If output validation fails, implement a single retry with the validation errors injected into the prompt as [CONSTRAINTS] feedback. If the retry also fails, escalate to a human review queue with the raw batch, the failed report, and the specific validation errors highlighted. Do not loop beyond one retry for compliance outputs—silent degradation is worse than a flagged failure. Human review integration: The report's sign-off fields should be left empty by the model and populated by a human reviewer through your application UI. Never allow the model to fill reviewer identity, approval timestamps, or signature fields. Audit logging: Log the full prompt input, model response, validation results, retry attempts, and final reviewer actions as an immutable audit record. Include model version, timestamp, and pipeline run ID. This log becomes part of the evidence package if the report is submitted to regulators. What to avoid: Do not use this prompt on unverified claims. Do not skip the input validation gate. Do not allow the model to generate sign-off attestations. Do not treat the report as final until a human reviewer has completed the sign-off fields and the audit log is persisted.