Policy Boundary Clarification Prompt for Safety Engineers

Safety engineers use this prompt when a policy boundary generates inconsistent refusals in production, when edge cases fall between existing policy categories, or when deploying a policy change that needs regression testing before release. The core job-to-be-done is converting vague policy language—'don't generate harmful content' or 'refuse illegal requests'—into operational definitions that a model can apply consistently and that a test harness can validate. Without this clarification step, safety policies drift: different model versions interpret the same policy differently, borderline requests produce unpredictable outcomes, and false-positive refusals erode user trust while false negatives create safety gaps.

This prompt is designed for the policy refinement workflow that happens before you write system instructions or configure guardrails. It expects you to provide the original policy text, a set of borderline requests that are causing confusion, and the risk tolerance for false positives versus false negatives in this domain. The output is not a final system prompt—it is a clarified policy document with explicit inclusion criteria, exclusion criteria, edge-case guidance, and a set of test scenarios you can run against your model. Each test scenario includes the request text, the expected outcome (accept or refuse), the policy clause that governs the decision, and a rationale that can be reviewed by human policy owners. For high-severity safety domains—child safety, self-harm, weapons, CBRN—the clarified policy and test suite must go through human policy review before any deployment.

Do not use this prompt when the policy is already well-specified with clear boundaries, when you need a system prompt rather than a policy specification, or when the ambiguity is in model capability rather than policy interpretation. This prompt does not replace human policy review for high-severity safety decisions, does not generate refusal response text, and does not tune refusal tone or style. If you need to calibrate how a refusal sounds rather than what should be refused, use the Refusal Style Calibration Prompt instead. After running this prompt, the next step is typically to feed the clarified policy into your system instructions, implement the test suite in your regression harness, and run the Policy Boundary Regression Test Prompt to validate that your model behavior matches the clarified boundaries.

This prompt template is designed for safety engineers who need to transform ambiguous or conflicting policy language into a precise, operational boundary definition. It forces the model to articulate what is explicitly included, what is explicitly excluded, and how to handle the gray zone in between. The output is not just a rewritten policy statement—it includes testable edge cases and a regression-testing scaffold that you can use to validate the clarification against known borderline requests before it ships to production.

textCopy
You are a safety policy engineer. Your task is to clarify an ambiguous safety policy boundary.

## INPUT POLICY
[AMBIGUOUS_POLICY_TEXT]

## KNOWN BORDERLINE REQUESTS
[EDGE_CASE_EXAMPLES]

## CONSTRAINTS
- Do not weaken any existing safety boundary.
- Do not invent new restrictions beyond what the policy intent supports.
- Prefer explicit inclusion and exclusion criteria over vague guidance.
- Flag cases that require human policy review rather than automated enforcement.

## OUTPUT SCHEMA
Return a JSON object with these fields:
{
  "clarified_policy": "string (the rewritten policy with explicit criteria)",
  "inclusion_criteria": ["string (list of conditions that make a request explicitly allowed)"],
  "exclusion_criteria": ["string (list of conditions that make a request explicitly refused)"],
  "gray_zone_guidance": "string (how to handle requests that fall between criteria)",
  "edge_case_decisions": [
    {
      "request": "string (the borderline request)",
      "decision": "allow | refuse | escalate",
      "rationale": "string (which criteria apply and why)",
      "confidence": "high | medium | low"
    }
  ],
  "regression_test_cases": [
    {
      "request": "string (a test case that should be allowed)",
      "expected_decision": "allow",
      "applicable_criteria": "string"
    },
    {
      "request": "string (a test case that should be refused)",
      "expected_decision": "refuse",
      "applicable_criteria": "string"
    }
  ],
  "escalation_triggers": ["string (conditions that require human review)"],
  "policy_gaps_identified": ["string (areas where the policy remains underspecified)"]
}

## INSTRUCTIONS
1. Identify the core safety intent behind the ambiguous policy.
2. Define explicit criteria that separate allowed from refused requests.
3. For each known borderline request, apply your criteria and explain the decision.
4. Generate at least three regression test cases for each decision direction.
5. Flag any request patterns that the clarified policy still cannot resolve.
6. If the policy intent itself is unclear, say so in policy_gaps_identified rather than guessing.

After pasting this template, replace [AMBIGUOUS_POLICY_TEXT] with the exact policy language that is causing over-refusal or inconsistent enforcement. Populate [EDGE_CASE_EXAMPLES] with real borderline requests from your production refusal logs or from red-team exercises. The more specific your examples, the more operational the output becomes. Do not skip the regression test cases—they are your pre-release safety net. Run them through your model before deploying the clarified policy, and treat any unexpected decision as a signal that the criteria need further refinement. For high-risk domains, route all escalation_triggers matches to a human reviewer and log every decision for audit.

The policy boundary clarification prompt is not a one-shot generator. It is the reasoning core of a policy refinement pipeline that must produce auditable, testable, and reversible policy changes. The harness wraps the prompt in a workflow that validates outputs against a regression suite, flags changes that alter existing refusal behavior, and gates publication behind human review. This section describes the minimum harness components required before this prompt can be trusted in a production safety system.

Workflow stages. The harness should execute in this order: (1) Load the current policy version, the ambiguous boundary description, and a set of known borderline requests with their expected outcomes. (2) Run the policy boundary clarification prompt to produce a clarified policy draft. (3) Validate the output schema—the draft must include explicit inclusion criteria, exclusion criteria, edge-case guidance, and test scenarios. Reject and retry if the schema is incomplete. (4) Run the regression test suite: apply the clarified policy to every known borderline request and compare the resulting accept/refuse decision against the expected outcome. Flag any decision that changed from the baseline. (5) If any regression flags are raised, route the draft to a human reviewer with a diff highlighting the changed decisions and the policy language that caused them. (6) If no regressions are detected, the draft still requires human approval before publication, but the review can focus on policy quality rather than breakage detection.

Validation and retry logic. The prompt output must conform to a strict schema: a clarified_policy object with inclusion_criteria, exclusion_criteria, edge_case_guidance, and test_scenarios arrays. Each test scenario must contain a request, expected_decision, and rationale. If the model returns malformed JSON, missing required fields, or fewer than three test scenarios, the harness should retry once with an explicit schema error message appended to the prompt context. If the second attempt also fails, escalate to a human with the raw output and the validation errors. Do not silently accept incomplete policy drafts.

Regression testing and gating. The regression suite is the primary safety mechanism. Maintain a golden dataset of at least 50 borderline requests with human-verified accept/refuse labels. After each policy clarification run, apply the new policy language to every request in the dataset using a separate evaluation prompt that takes the clarified policy and a request as input and returns a decision. Compare decisions against the golden labels. Any decision that flips from accept to refuse or refuse to accept is a regression. The harness must produce a regression report showing the request, the old decision, the new decision, and the policy clause that drove the change. This report becomes the primary artifact for human review.

Human review gates. No clarified policy should be published without human approval. The harness should produce a review packet containing: the original ambiguous boundary description, the clarified policy draft, the regression report (if any flags), and a summary of how many test scenarios the model generated and whether they cover the ambiguous cases. The human reviewer must explicitly approve or reject the draft. If rejected, the reviewer's feedback should be captured and fed back into the prompt as additional context for the next iteration. This feedback loop is critical for improving the prompt's policy reasoning over time.

Model choice and deployment. This prompt requires strong reasoning and instruction-following capabilities. Use a frontier model (GPT-4o, Claude 3.5 Sonnet, or equivalent) with low temperature (0.0–0.2) for deterministic policy output. Do not use smaller or faster models for the clarification step—policy language errors compound across every downstream refusal decision. The regression evaluation step can use a faster model if the evaluation prompt is simple and the golden dataset is large enough to catch errors. Log every run: the prompt version, the model version, the raw output, the validation result, the regression diff, and the human reviewer's decision. This audit trail is essential for governance and for debugging policy drift over time.