Verification Policy Compliance Check Prompt

This prompt is for governance and compliance teams who need to audit verification decisions made by automated fact-checking pipelines or human reviewers. It checks whether a verification outcome and its supporting process comply with organizational policies such as evidence sufficiency standards, source authority requirements, escalation rules, and handling restrictions for sensitive content. The core job-to-be-done is producing an auditable compliance assessment that references specific policy clauses, not re-verifying the claim itself. The ideal user is a compliance officer, a governance lead, or an audit team member responsible for ensuring that the verification pipeline operates within defined risk and quality boundaries before a decision is published, logged as final, or acted upon.

Use this prompt only after a verification decision has been made. It requires three concrete inputs: a defined policy document, a structured verification record, and a need for a traceable compliance report. The prompt assumes the policy document contains explicit, referenceable clauses. Do not use this prompt as a replacement for the verification decision itself, as a real-time gate on breaking news, or in any workflow where the policy is vague, unwritten, or exists only as tribal knowledge. It is also unsuitable for evaluating the factual accuracy of a claim; its sole function is to assess the process and outcome against a known governance standard. Attempting to use it without a structured policy will result in generic, unactionable output.

The output is a compliance assessment, not a binary pass/fail flag. It should flag specific violations, reference the exact policy clauses in question, and recommend remediation steps. Before integrating this prompt into a production pipeline, you must test it against a golden dataset of known policy violation patterns and edge cases, such as a decision made with insufficient sources or a high-risk claim that bypassed human review. The next step is to wire this prompt into a post-verification, pre-finalization harness that logs the compliance report alongside the verification record, creating a complete audit trail. Avoid the mistake of treating a 'compliant' result as a guarantee of correctness; it only confirms adherence to the stated process.

This prompt template is designed to be wired directly into your verification pipeline. It takes a verification decision record and a set of organizational policies, then produces a structured compliance assessment. The model is instructed to act as a compliance analyst, cross-referencing the decision's evidence, confidence, and routing against explicit policy rules. The output is a machine-readable JSON object suitable for logging, auditing, or triggering remediation workflows.

textCopy
You are a compliance analyst for an AI-assisted verification pipeline. Your task is to audit a single verification decision against the provided organizational policies. You must be precise, evidence-based, and conservative. If a policy is unclear or the decision's details are insufficient, flag it for human review.

## INPUTS

### Verification Decision Record
[DECISION_RECORD]

### Organizational Policies
[POLICIES]

## INSTRUCTIONS
1.  **Parse the Decision:** Identify the original claim, the verification outcome (True, False, Unverified, Disputed), the confidence score, the evidence sources used, and the routing decision (Auto-Verified, Escalated to Human).
2.  **Policy Mapping:** For each relevant policy in [POLICIES], determine if the verification decision is compliant, non-compliant, or if compliance is uncertain.
3.  **Violation Flagging:** For any non-compliant finding, explicitly state the policy clause violated, the specific detail from the decision record that constitutes the violation, and the severity (Critical, High, Medium, Low).
4.  **Remediation:** For each violation, propose a concrete remediation step that would bring the decision into compliance.
5.  **Uncertainty Handling:** If the decision record lacks the information needed to assess a policy, flag the policy as "Unable to Assess" and specify the missing information.

## CONSTRAINTS
- Do not re-evaluate the factual accuracy of the claim itself. Only assess the process and decision against the policies.
- If [POLICIES] is empty, flag the entire decision as "No Policies Provided" and require human review.
- Base your assessment strictly on the provided text. Do not infer or assume external context.
- If the confidence score is below the threshold defined in [POLICIES] for auto-verification, but the decision was auto-verified, this is a Critical violation.

## OUTPUT_SCHEMA
You must respond with a single, valid JSON object conforming to this schema:
{
  "assessment_id": "string, a unique ID for this compliance check",
  "decision_id": "string, the ID from the [DECISION_RECORD]",
  "overall_compliance": "Compliant | Non-Compliant | Unable to Assess",
  "findings": [
    {
      "policy_id": "string, reference to the specific policy clause",
      "policy_name": "string, short name of the policy",
      "compliance_status": "Compliant | Non-Compliant | Unable to Assess",
      "rationale": "string, concise explanation of the finding",
      "violation_detail": "string or null, specific non-compliant detail from the decision record",
      "severity": "Critical | High | Medium | Low | null",
      "remediation": "string or null, concrete step to achieve compliance"
    }
  ],
  "requires_human_review": boolean,
  "human_review_reason": "string or null, explanation if human review is needed"
}

To adapt this template, replace [DECISION_RECORD] with a JSON or structured text object from your verification system. This object should contain the claim, the verdict, the confidence score, and the routing path. Replace [POLICIES] with a structured list of your organization's rules, such as 'Auto-verification requires a confidence score > 0.95' or 'Claims about financial performance must always be reviewed by a human.' The prompt's strength lies in its explicit instruction to separate process compliance from factual re-evaluation, preventing the model from drifting into re-doing the original verification work. For high-stakes domains, always route the output where overall_compliance is "Non-Compliant" or requires_human_review is true to a human auditor before taking any automated action.

This prompt is not a standalone chat interaction; it is a compliance gate inside a verification pipeline. The harness must treat the prompt as a deterministic check that either passes, flags violations, or escalates for human review. Because policy compliance directly affects audit readiness and regulatory posture, the implementation must prioritize explainability and false-negative prevention over raw speed. Wire the prompt after a verification decision has been proposed but before that decision is published or acted upon. The harness should never allow a verification outcome to bypass the compliance check, even under latency pressure.

Build the harness with three mandatory stages: pre-validation, model invocation with structured output parsing, and post-validation with retry logic. Pre-validation confirms that the input payload contains all required fields—[POLICY_DOCUMENT], [VERIFICATION_DECISION], [EVIDENCE_CHAIN], and [CLAIM_CONTEXT]—and rejects malformed requests before consuming model tokens. Model invocation should use a low-temperature setting (0.0–0.2) with a strict JSON schema specifying compliance_status (enum: compliant, non_compliant, uncertain), violated_policy_ids (array of strings), remediation_required (boolean), and human_review_required (boolean). Post-validation must check that non_compliant status always includes at least one violated_policy_id and that remediation_required is never false when violations exist. If parsing fails or post-validation catches a structural inconsistency, retry once with the same payload and a stronger instruction to adhere to the output schema. After a second failure, escalate to a human reviewer with the raw model output and validation error context.

Latency budgets require special attention. Compliance checks add overhead to verification pipelines, and time-sensitive verifications cannot tolerate unbounded delays. Implement a configurable timeout—start at 5 seconds for the model call—and a fast-path bypass for low-risk verification categories defined in your policy. The bypass must be an explicit policy rule, not a silent skip. Log every compliance check result, including bypass decisions, to an append-only audit store with the prompt version, model identifier, timestamp, input hash, and full output payload. This audit trail is non-negotiable for governance reviews. Avoid caching compliance results across different verification decisions, even if the policy document is identical, because the interaction between policy and specific evidence chains demands fresh evaluation each time. The next step is to build a regression test suite using known policy violation patterns and edge cases before deploying this harness to production.