Citation Verification for Compliance Review Prompt

This prompt is built for compliance engineers and audit teams operating in regulated industries—pharmaceuticals, medical devices, financial services, and legal operations—who must verify that AI-generated claims are actually supported by cited regulatory documents, standards, or internal policies. The job-to-be-done is not a general-purpose citation check. It is a structured compliance verification: for every claim in a generated output, confirm that the cited source exists, that the specific passage supports the claim, that required regulatory disclaimers are present, and that evidence meets domain-specific documentation standards. You should use this prompt when you already have three things ready: the AI-generated text containing citations, the full text of every cited source document, and a defined set of regulatory requirements or documentation standards that apply to your domain.

Do not use this prompt when you only need to check whether a citation format is correct, or when you are verifying citations against a general web corpus without domain-specific regulatory rules. This prompt assumes the evidence is already retrieved and available for inspection—it does not perform retrieval. It also assumes you have defined what counts as acceptable evidence in your regulatory context, such as requiring primary source documents rather than secondary summaries, or mandating specific disclaimer language. If you lack the source documents or the regulatory requirements, the prompt will produce unreliable results because it cannot verify what it cannot read. For format-only validation, use the Citation Format Validation Prompt instead. For detecting entirely fabricated citations, pair this prompt with the Hallucinated Citation Detection Prompt as a pre-filter.

The output is a compliance-focused verification report with regulatory gap flags, not a simple supported/unsupported binary. Each claim receives a support assessment, missing disclaimers are flagged, and evidence that fails to meet domain-specific documentation standards is called out explicitly. Because this workflow operates in high-risk regulated contexts, the implementation must include human review of every flagged gap before any compliance decision is made. Wire the prompt into a pipeline that logs every verification decision, preserves the full source text used for verification, and routes gap reports to a human review queue. Never use this prompt's output to automatically pass or fail a compliance submission without human approval. The next step after reading this section is to gather your three required inputs and review the prompt template in the following section.

The following prompt template is designed for compliance engineers who need to verify that AI-generated outputs meet regulatory documentation standards. It checks whether cited sources actually support the claims made, identifies missing required disclaimers, and flags gaps against domain-specific regulatory requirements. The template uses square-bracket placeholders that you must replace with your specific regulatory context, evidence documents, and output requirements before use.

textCopy
You are a compliance citation verification specialist operating in a [REGULATORY_DOMAIN] environment governed by [APPLICABLE_REGULATIONS_OR_STANDARDS]. Your task is to verify whether the claims in a generated output are properly supported by cited sources and meet all regulatory documentation requirements.

## INPUT
**Generated Output:** [GENERATED_OUTPUT_TEXT]

**Cited Sources:** [CITED_SOURCES_WITH_IDENTIFIERS]

**Source Documents:** [FULL_SOURCE_DOCUMENTS_OR_ACCESS_INSTRUCTIONS]

**Regulatory Requirements:** [SPECIFIC_REGULATORY_REQUIREMENTS_OR_STANDARDS_DOCUMENT]

**Required Disclaimers:** [LIST_OF_REQUIRED_DISCLAIMERS_OR_FORMAT_REQUIREMENTS]

## VERIFICATION TASKS
1. **Claim-Source Verification:** For each factual claim in the generated output, determine whether the cited source actually contains supporting evidence. Flag any claim where the cited source does not support the statement.
2. **Citation Existence Check:** Verify that every cited source exists in the provided source documents. Flag fabricated or hallucinated citations with a [HALLUCINATION] severity marker.
3. **Regulatory Gap Analysis:** Check whether the generated output and its citations meet all requirements specified in the regulatory requirements document. Identify specific gaps where regulatory standards are not satisfied.
4. **Disclaimer Completeness:** Verify that all required disclaimers are present in the output. Flag missing disclaimers with the specific regulatory reference requiring them.
5. **Evidence Sufficiency Assessment:** For each claim, assess whether the cited evidence is sufficient to meet the evidentiary standard required by [EVIDENTIARY_STANDARD]. Note where evidence is partial, indirect, or insufficient.

## OUTPUT SCHEMA
Produce a structured verification report in JSON format:
```json
{
  "verification_metadata": {
    "verification_id": "string",
    "verification_timestamp": "ISO8601",
    "regulatory_domain": "string",
    "applicable_standards": ["string"],
    "reviewer_role": "compliance_citation_specialist"
  },
  "claim_verifications": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "cited_source_id": "string",
      "support_status": "FULLY_SUPPORTED | PARTIALLY_SUPPORTED | UNSUPPORTED | CONTRADICTED",
      "evidence_excerpt": "string or null",
      "verification_notes": "string",
      "requires_human_review": boolean
    }
  ],
  "citation_issues": [
    {
      "citation_id": "string",
      "issue_type": "HALLUCINATED | UNVERIFIABLE | INCOMPLETE | MISMATCHED",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "description": "string",
      "recommended_action": "string"
    }
  ],
  "regulatory_gaps": [
    {
      "requirement_reference": "string",
      "requirement_description": "string",
      "gap_description": "string",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "remediation_guidance": "string"
    }
  ],
  "missing_disclaimers": [
    {
      "required_disclaimer": "string",
      "regulatory_basis": "string",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW"
    }
  ],
  "overall_assessment": {
    "compliance_status": "PASS | CONDITIONAL_PASS | FAIL | INCOMPLETE",
    "critical_findings_count": number,
    "requires_legal_review": boolean,
    "summary": "string"
  }
}

CONSTRAINTS

• Never fabricate evidence or claim support where none exists. If a source does not support a claim, mark it as UNSUPPORTED.
• When regulatory requirements cannot be fully assessed from provided documents, note this as a limitation rather than assuming compliance.
• Flag all findings that require human review, especially those with regulatory or legal implications.
• Do not provide legal advice. Your role is verification against documented requirements, not legal interpretation.
• If [RISK_LEVEL] is HIGH or CRITICAL, escalate all UNSUPPORTED and CONTRADICTED findings for mandatory human review.

EXAMPLES

[FEW_SHOT_EXAMPLES_OF_VERIFICATION_OUTPUTS]

Begin verification now.

To adapt this template for your compliance workflow, replace the square-bracket placeholders with your specific context. The [REGULATORY_DOMAIN] and [APPLICABLE_REGULATIONS_OR_STANDARDS] fields define the compliance framework—replace these with your actual domain and governing standards. The [CITED_SOURCES_WITH_IDENTIFIERS] and [FULL_SOURCE_DOCUMENTS_OR_ACCESS_INSTRUCTIONS] fields must contain the complete evidence set; partial source access will produce incomplete verification reports. The [EVIDENTIARY_STANDARD] placeholder should reference your domain's specific burden-of-proof requirements. For high-risk regulated environments, set [RISK_LEVEL] to HIGH or CRITICAL to enforce mandatory human review on all unsupported findings. The [FEW_SHOT_EXAMPLES_OF_VERIFICATION_OUTPUTS] placeholder should contain 2-3 annotated examples showing correct verification outputs for your domain, including edge cases where evidence is partial or contradictory.

After deploying this prompt, implement a validation layer that checks the JSON output against your expected schema before the verification report enters any downstream system. For regulated workflows, route all findings marked requires_human_review: true or with CRITICAL severity to a compliance review queue. Do not rely solely on the model's verification without human spot-checking a sample of outputs against source documents, especially during the first weeks of deployment. If you observe systematic under-flagging of unsupported claims, add more domain-specific counterexamples to the [FEW_SHOT_EXAMPLES] section showing the model where it previously failed to detect gaps.

The Citation Verification prompt is not a standalone chatbot; it is a deterministic step inside a compliance review pipeline. The harness should treat the prompt as a stateless function that receives a structured payload—typically a generated claim, its cited source text, and the regulatory domain context—and returns a structured verification report. The application layer is responsible for assembling the input, calling the model, validating the output schema, and routing the result to the appropriate downstream action: approval, flagging, human review, or audit logging.

Start by defining a strict input contract. The prompt expects [CLAIM], [CITED_SOURCE_TEXT], [REGULATORY_DOMAIN], and [REQUIRED_DISCLAIMERS] as square-bracket placeholders. The application must resolve these from upstream systems before invocation. For example, [CITED_SOURCE_TEXT] should be the exact passage the model referenced, not a document summary. [REGULATORY_DOMAIN] should map to a controlled vocabulary (e.g., FDA_21_CFR_Part_11, GDPR_Art_5, SOX_302) so the prompt's compliance checks are scoped correctly. The harness should reject requests where required fields are missing or where source text exceeds a token limit that would cause the model to truncate evidence.

After the model returns a response, the harness must validate the output against the expected schema before any downstream action. The prompt template specifies a JSON structure with fields like claim_supported, support_level, regulatory_gaps, and disclaimer_compliance. Use a JSON Schema validator in the application layer to confirm every required field is present and correctly typed. If validation fails, implement a retry loop with a maximum of two additional attempts, appending the validation error to the prompt context so the model can self-correct. Log every validation failure for prompt debugging. For high-risk compliance workflows, route any output where support_level is PARTIAL or NONE directly to a human review queue with the full verification payload attached.

Model choice matters. For regulatory compliance verification, prefer models with strong instruction-following and low hallucination rates on structured extraction tasks. Claude 3.5 Sonnet and GPT-4o are strong defaults; avoid smaller or older models that may confuse PARTIAL support with FULL support. Set temperature=0 to maximize determinism. If your deployment requires on-premise or air-gapped operation, test open-weight models like Llama 3.1 70B against a golden dataset of verified compliance reports before cutting over. The harness should support model routing so you can escalate ambiguous cases to a stronger model or flag them for human review.

Auditability is non-negotiable. Every invocation must be logged with a unique verification_id, the full input payload, the raw model response, the validated output, and the final routing decision (approved, flagged, escalated). Store these records in an append-only audit log. If a regulatory auditor asks how a specific claim was verified, the harness must be able to reproduce the exact prompt, model response, and validation result. Do not rely on the model's internal reasoning as the audit trail—the structured output fields (regulatory_gaps, disclaimer_compliance) are the auditable artifacts. The prompt itself should instruct the model to cite specific regulatory clauses when flagging gaps, which makes the verification report self-documenting.

Finally, build an eval harness before you ship. Create a golden dataset of 50–100 claim-source pairs with known compliance outcomes, including edge cases: partially supported claims, missing disclaimers, outdated regulatory references, and claims that cite irrelevant passages. Run the prompt against this dataset after every prompt change and measure precision and recall on claim_supported classification. Set a minimum F1 threshold (0.90 is a reasonable starting point for compliance workflows) and block deployment if the score drops. The eval harness should also measure schema compliance rate and retry frequency—if more than 5% of calls require a retry, the prompt or the validator needs attention before production traffic hits it.