Override Decision Policy Compliance Check Prompt

Use this prompt when a human reviewer has decided to override an AI system's recommendation, refusal, or autonomous decision, and you need to verify that the override complies with organizational policy before it executes. The primary user is a compliance engineer embedding a policy gate into an override workflow. The prompt assumes you have already retrieved the relevant policy documents and the structured override justification. It produces a compliance assessment with specific policy references, flagged gaps, and a recommended action: proceed, block, or escalate.

This prompt is designed for a pre-execution gate, not a post-hoc audit. The ideal workflow is synchronous: a human submits an override, the system retrieves policy documents via RAG, the prompt evaluates the justification against those policies, and the output determines whether the action proceeds. The prompt requires a structured override justification as input, which should include the original AI decision, the proposed override, the reviewer's rationale, and any risk context. The policy documents must be retrieved and provided as context; this prompt does not perform retrieval itself. The output is a structured compliance assessment, not a simple yes/no, because borderline cases require escalation rather than binary decisions.

Do not use this prompt for real-time decision-making where policy retrieval latency would block a user. It is not a replacement for legal review in regulated domains—if the override involves legal interpretation, the prompt should escalate for human legal review rather than attempting to resolve ambiguity. Do not use this prompt without a human-in-the-loop confirmation step for any violation or gap it flags. The prompt identifies compliance issues; it does not resolve them. Finally, do not use this prompt when the override justification is unstructured free-text; pair it with a structured justification extraction prompt first to ensure the compliance check has reliable input.

This template is the core instruction set for the Override Decision Policy Compliance Check Prompt. It is designed to be wired into a production harness that retrieves the relevant policy documents, the original AI decision, and the proposed human override. The prompt instructs the model to act as a compliance engineer, cross-referencing the override against specific policy clauses and producing a structured assessment. Do not use this prompt in isolation; it requires a retrieval-augmented generation (RAG) step to supply the authoritative policy text, ensuring the model grounds its analysis in your actual rules rather than general knowledge.

textCopy
You are a compliance review agent. Your task is to evaluate a proposed human override of an AI decision against the organization's official policy documents.

## INPUT DATA
- **Original AI Decision:** [ORIGINAL_AI_DECISION]
- **Proposed Human Override:** [PROPOSED_OVERRIDE]
- **Override Justification:** [OVERRIDE_JUSTIFICATION]
- **Retrieved Policy Documents:** [POLICY_DOCUMENTS]
- **Risk Level of Action:** [RISK_LEVEL]

## OUTPUT SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "compliance_status": "compliant" | "non_compliant" | "policy_gap" | "requires_clarification",
  "policy_references": [
    {
      "policy_id": "string",
      "clause": "string",
      "relevance": "string"
    }
  ],
  "gaps_flagged": [
    {
      "gap_type": "violation" | "missing_authorization" | "insufficient_justification" | "policy_silence",
      "description": "string",
      "severity": "critical" | "high" | "medium" | "low"
    }
  ],
  "recommended_action": "proceed" | "block" | "escalate_for_review" | "request_clarification",
  "assessment_summary": "A concise, factual summary of the compliance evaluation."
}

## CONSTRAINTS
1. **Ground every finding in a specific policy reference.** If a policy document does not explicitly address a point, flag it as a 'policy_gap' or 'policy_silence' rather than inferring a rule.
2. **Do not make risk tolerance decisions.** If the policy is silent on a high-risk action, your recommended_action must be 'escalate_for_review'.
3. **Treat the override justification as a claim to be verified.** If the justification contradicts the policy or the original decision's context, flag it as 'insufficient_justification'.
4. **If multiple policies conflict, flag the conflict** and set compliance_status to 'requires_clarification'.
5. **For any 'non_compliant' or 'policy_gap' finding on a high-risk action, the recommended_action must be 'block' or 'escalate_for_review'.**

## EVALUATION STEPS
1. Parse the original AI decision and the proposed override to understand the delta.
2. Identify all policy clauses in the retrieved documents that govern this type of action.
3. For each relevant clause, determine if the override is permitted, prohibited, or unaddressed.
4. Evaluate the override justification against policy requirements for documentation and authorization.
5. Assemble the output JSON with specific references and a clear recommended action.

To adapt this template, replace the square-bracket placeholders with live data from your application. The [POLICY_DOCUMENTS] placeholder should be populated by a retrieval system that searches your policy knowledge base using the action type and risk category as queries. The [RISK_LEVEL] input should come from your application's risk scoring model, not from the LLM's own judgment. After generating the compliance assessment, your harness must enforce a human-in-the-loop confirmation step for any output where recommended_action is not proceed. Log the full assessment, the final human decision, and the policy documents used for a complete audit trail.

This prompt is not a standalone chat interaction; it is a synchronous gate inside an override execution pipeline. When a human reviewer submits an override request, the application must first retrieve the relevant policy documents, assemble the context, and call this prompt before the override is committed. The prompt's output determines whether the override proceeds, is blocked, or is routed for secondary review. Treat this as a deterministic policy evaluation step, not a conversational assistant.

The implementation harness requires three components: a policy retrieval system, a structured invocation layer, and a post-inference decision router. Before calling the model, use the override's target decision type and the reviewer's department to query your policy knowledge base (vector search over policy documents, a graph of regulatory rules, or a SQL query against a compliance rules table). Retrieve the top-k relevant policy sections and format them into the [POLICY_DOCUMENTS] placeholder. The invocation layer should set a low temperature (0.0–0.2) for deterministic compliance assessments and enforce a strict JSON output schema using the model's structured output or function-calling capabilities. After receiving the response, validate that the compliance_status field is one of the allowed enum values (COMPLIANT, NON_COMPLIANT, CONDITIONAL). If the status is NON_COMPLIANT, block the override and log the violation. If CONDITIONAL, route to a senior compliance officer with the prompt's required_conditions and policy_gaps fields pre-populated in the review UI. Only COMPLIANT overrides should proceed automatically.

For high-risk domains such as financial controls or healthcare data access, add a human-in-the-loop confirmation even for COMPLIANT assessments. The harness should log the full prompt input, model response, policy document versions, and reviewer identity to an append-only audit store before any override is executed. Implement a retry strategy for malformed JSON responses: if the output fails schema validation, retry once with a stricter system message that includes the exact validation error. If the retry also fails, escalate the entire override request to a manual review queue with the raw model output attached. Do not silently default to allowing the override on failure—fail closed. Model choice should favor models with strong instruction-following and low hallucination rates on structured extraction tasks; test across at least two model families to ensure the prompt's policy reasoning generalizes and does not rely on a single vendor's behavior.