Policy Exception Handling Prompt Template

This prompt is designed for operations teams, trust-and-safety engineers, and compliance officers who must process a user request that violates a defined organizational policy but has a legitimate, documented reason for an override. The job-to-be-done is not to decide whether to grant an exception—that decision belongs to a human—but to produce a structured, auditable exception record that captures the justification, the approving authority, the time-bound access window, and the enforcement checks required when the exception expires. Use this prompt when your system already has a policy enforcement layer that correctly identifies a violation and you need a controlled, reviewable path to override it without weakening the underlying policy.

The prompt requires several concrete inputs to function safely. You must provide the original violating request, the specific policy clause that was triggered, the override justification from the requestor, and the identity of the approving authority. The output is a structured exception document that includes an approval routing recommendation, a time-bound grant with an explicit expiration timestamp, and an audit trail entry suitable for compliance review. Do not use this prompt for real-time, automated exception granting without human approval. Do not use it when the policy itself is ambiguous or untested—resolve the policy definition first using a policy-to-instruction translation or boundary extraction prompt. Do not use it for requests that fall into legally regulated domains without involving qualified legal review.

The primary risk in exception handling is normalization of deviance: if exceptions become easy to grant, the policy boundary erodes. This prompt mitigates that risk by making every exception explicit, time-limited, and auditable. Wire the output into an approval queue that requires a human reviewer to confirm the exception before it takes effect. Log the full exception record, the reviewer's identity, and the timestamp. Schedule an automated enforcement check at the expiration time to revoke access or re-require compliance. Before deploying, test the prompt against edge cases: expired exceptions, missing justification, policy clauses that prohibit exceptions entirely, and requestors attempting to self-approve. The next step after reading this section is to review the prompt template, adapt the placeholders to your policy schema, and build the approval and expiration enforcement harness before any exception goes live.

This template handles requests that violate standard policy but have legitimate override reasons. It produces structured exception documentation, routes to appropriate approvers based on risk tier, and enforces time-bound access with expiration checks. The prompt is designed to be wired into an approval workflow where human review is mandatory before any exception is granted.

textCopy
You are a policy exception handler for [ORGANIZATION_NAME]. Your role is to process requests that violate standard policy but may qualify for a documented exception. You do not approve exceptions. You prepare structured exception documentation for human review.

## POLICY CONTEXT
[POLICY_DOCUMENT]

## EXCEPTION CRITERIA
[EXCEPTION_CRITERIA]

## REQUEST DETAILS
Requester: [REQUESTER_ID]
Request: [USER_REQUEST]
Policy Violated: [VIOLATED_POLICY_ID]
Override Reason Provided: [OVERRIDE_REASON]

## RISK ASSESSMENT
Risk Tier Definitions:
[RISK_TIER_DEFINITIONS]

## OUTPUT SCHEMA
Produce a JSON object with these exact fields:
{
  "exception_id": "string, unique identifier",
  "violated_policy": "string, policy reference",
  "violation_severity": "string, one of: [SEVERITY_LEVELS]",
  "override_rationale": "string, requester's stated reason",
  "risk_tier": "string, one of: [RISK_TIERS]",
  "required_approvers": ["string, list of role IDs"],
  "recommended_duration_hours": "number, 0 for permanent",
  "expiration_timestamp": "string, ISO 8601 or null",
  "conditions": ["string, list of constraints on the exception"],
  "audit_evidence": ["string, list of supporting references"],
  "confidence_score": "number, 0.0 to 1.0",
  "escalation_required": "boolean",
  "notes": "string, additional context for reviewers"
}

## CONSTRAINTS
- If the override reason does not match any defined exception criterion, set escalation_required to true and explain why in notes.
- If risk_tier is [HIGHEST_RISK_TIER], require at least [MIN_APPROVERS] approvers.
- If recommended_duration_hours exceeds [MAX_DURATION], flag for review.
- Never approve an exception. Only document and route.
- If confidence_score is below [CONFIDENCE_THRESHOLD], escalate regardless of other factors.
- Cite specific policy sections in audit_evidence.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## INPUT
[REQUEST_DETAILS]

Adapt this template by replacing each square-bracket placeholder with your organization's specific values. The [POLICY_DOCUMENT] should contain the full text of relevant policies. The [EXCEPTION_CRITERIA] must enumerate the exact conditions under which an exception can be considered. The [RISK_TIER_DEFINITIONS] should map your internal risk levels to concrete criteria. The [FEW_SHOT_EXAMPLES] should include at least three examples: one clear denial, one clear exception with conditions, and one ambiguous case requiring escalation. Before deploying, validate that the output schema matches your downstream approval system's expected payload format. Run at least 20 test cases through the prompt and manually review every output where confidence_score falls below 0.85 or escalation_required is true.

This prompt is not a standalone chatbot interaction. It is a structured decision point inside a policy enforcement pipeline. The application should invoke this prompt only after a request has been classified as a policy violation and a human operator or upstream system has indicated a legitimate override reason exists. The prompt's job is to produce a documented, auditable exception record—not to decide whether the exception is valid. That decision must be made before the prompt runs, or escalated for approval after the prompt produces its output.

Wire the prompt into a workflow engine or approval queue. The required inputs—[REQUEST_CONTENT], [VIOLATED_POLICY_ID], [OVERRIDE_REASON], [REQUESTER_ID], and [APPROVER_ID]—must be populated from upstream systems, not free-text user input. After the model returns the structured exception record, validate the output against a strict schema: confirm that exception_id is present, expiration_timestamp is in the future, approval_chain is non-empty, and audit_trail contains at least one entry with a timestamp and actor. If validation fails, retry once with the validation errors injected into [CONSTRAINTS]. If the retry also fails, route to a human reviewer with the partial output and error details. Log every invocation—including inputs, outputs, validation results, and reviewer actions—to an append-only audit store. For high-risk policy domains, require a second human approval before the exception is committed to the enforcement system.

Model choice matters. Use a model with strong structured output support and low refusal rates on administrative documentation tasks. GPT-4o and Claude 3.5 Sonnet are suitable defaults. Avoid models that over-refuse on policy-related language, as the prompt itself discusses policy violations. Set temperature to 0 or near-zero to maximize schema consistency. If your application uses tool-calling, expose a create_policy_exception function with the output schema as its parameters, and instruct the model to call it. This gives you a parseable function call instead of relying on text extraction. Do not use this prompt in real-time blocking flows; the exception handling path should be asynchronous to avoid adding latency to user-facing requests. Finally, build a scheduled job that queries your audit store for exceptions where expiration_timestamp < now() and status != 'expired', and automatically revokes them, logging the revocation event.