Policy Boundary Ambiguity Escalation Prompt

This prompt is designed for AI systems that operate under a defined policy framework—such as content moderation, data access, financial controls, or operational runbooks—and encounter a request that falls into a gray zone between clearly allowed and clearly prohibited. The job-to-be-done is not to make a decision, but to produce a structured escalation package that captures the ambiguous request, the specific policy clause in question, the system's preliminary analysis, and a recommended path for human adjudication. The ideal user is an AI engineer or product developer building a human-in-the-loop workflow where the cost of a wrong autonomous decision is high, and the system must never silently resolve policy ambiguity on its own.

Use this prompt when your application has a codified policy (a set of rules, an acceptable use policy, a compliance framework, or operational guardrails) and the model can access that policy text as part of its context. The prompt assumes that the system has already attempted to classify the request against the policy and found it to be borderline—this is not a first-pass classification prompt. It is an escalation prompt for the cases that remain after initial policy checks. The required inputs include the full user request, the specific policy clause or clauses that are ambiguous, any relevant context (user role, request history, risk signals), and a defined output schema for the escalation record. Do not use this prompt for requests that are clearly allowed or clearly blocked; those should be handled deterministically or by simpler classification prompts. Do not use it when no policy text exists—this prompt requires grounding in explicit, referenceable policy language.

The output of this prompt is a structured escalation record, not an action. The system that calls this prompt must be architected to route that record to a human review queue, log it for audit, and block the underlying action until adjudication is complete. Before deploying, test the prompt against a golden set of borderline cases where the correct escalation decision is known, and measure both false negatives (cases that should have escalated but didn't) and false positives (clear cases that unnecessarily hit the review queue). The next step after reading this section is to review the prompt template, adapt the placeholders to your policy structure, and wire the output into your review and logging infrastructure.

The following prompt template is designed to be integrated into an AI system's decision loop. Its job is to intercept requests that land in a gray area of your defined policies, where neither an outright refusal nor an unqualified execution is clearly correct. The prompt forces the model to articulate the ambiguity, cite the specific policy clause in question, and package the context for a human reviewer. This prevents the system from silently making a risky decision.

textCopy
You are a policy enforcement agent. Your task is to analyze a user request that has been flagged as falling near the boundary of an allowed policy. You must not approve or deny the request yourself. Instead, you will produce a structured escalation package for a human adjudicator.

## INPUT
[REQUEST]
[POLICY_DOCUMENT]
[CONTEXT]

## TASK
1.  **Identify the Ambiguity:** Explain why the request is at the boundary of the policy. Quote the specific, ambiguous clause from [POLICY_DOCUMENT].
2.  **Assess the Risk:** State the primary risk of approving the request and the primary risk of denying it, based on [CONTEXT].
3.  **Recommend a Path:** Provide a single, clear recommendation for the human adjudicator (e.g., "Approve with constraints," "Deny and explain," "Request more information from user").
4.  **Draft a Response:** Draft the response that should be sent to the user if the adjudicator chooses to deny or ask for clarification. Do not draft an approval message.

## CONSTRAINTS
- Do not fabricate policy clauses. Only quote directly from [POLICY_DOCUMENT].
- If the request is clearly allowed or clearly disallowed by the policy, output "NO_AMBIGUITY" and explain why.
- Your recommendation must be actionable and specific. Do not just say "be careful."
- Output only the JSON object described in [OUTPUT_SCHEMA]. Do not include any other text.

## OUTPUT_SCHEMA
{
  "status": "AMBIGUITY_DETECTED" | "NO_AMBIGUITY",
  "ambiguity_report": {
    "request_summary": "string",
    "ambiguous_policy_clause": "string (exact quote)",
    "ambiguity_explanation": "string",
    "risk_of_approval": "string",
    "risk_of_denial": "string"
  },
  "recommendation": "string",
  "drafted_user_response": "string (only for denial or clarification)"
}

To adapt this template, replace the placeholders with your application's live data. [REQUEST] should be the raw user input. [POLICY_DOCUMENT] is the full text of your relevant policy, not just a summary. [CONTEXT] should include any relevant user history, account standing, or previous related tickets. The [OUTPUT_SCHEMA] is critical; your application harness must parse this JSON to route the escalation correctly. If the status is NO_AMBIGUITY, your system should log this as a potential false-positive from the upstream ambiguity detector and proceed with the standard allow/deny flow. If AMBIGUITY_DETECTED, the entire JSON object should be attached to a ticket in your human review queue.

This prompt is a safety-critical component, not a standalone chatbot. It must be wired into an application harness that enforces a strict decision gate: the model's output determines whether the system proceeds, blocks, or escalates. The harness should never allow the AI to silently execute a borderline action. Instead, the prompt's structured output is parsed by the application to trigger one of three paths: proceed (action is clearly within policy), block (action is clearly outside policy), or escalate (ambiguity detected, human review required). The harness is responsible for enforcing that the 'escalate' path is the default when parsing fails or confidence is low, making ambiguity the safest failure mode.

The implementation should wrap the LLM call in a validation and retry layer. First, validate that the model's output strictly conforms to the expected JSON schema, including the decision enum (PROCEED, BLOCK, ESCALATE) and the required fields for each decision path. If the output fails schema validation, retry the prompt once with the validation error injected as a new [CONSTRAINT]. If the retry also fails, force the ESCALATE path and log the raw output for debugging. For the ESCALATE decision, the harness must extract the escalation_package and push it to a human review queue—such as a Slack channel, a Jira ticket, or an internal review tool—with a unique escalation_id for tracking. The system must then block the original action until a human adjudicator provides a PROCEED or BLOCK override via an API callback.

For high-throughput systems, consider adding a pre-filter to avoid calling the LLM for every request. A simple rule-based check can handle clear-cut cases (e.g., an allowlist of safe actions or a denylist of prohibited ones). Only requests that fall into the gray area should hit this prompt. All decisions, including the model's reasoning and any human overrides, must be logged immutably with the escalation_id, timestamp, user context, and final outcome. This audit trail is essential for policy governance and for fine-tuning the boundary definitions over time. Do not use this prompt with a model that has a context window too small to hold the full policy document; truncation of the policy clause is a direct path to a compliance failure.