Refusal Policy Portability Prompt Template

This prompt is for trust and safety teams, AI platform engineers, and policy authors who need a single, auditable refusal policy specification that can be adapted for multiple model providers (e.g., OpenAI, Anthropic, Google, open-weight models). Use it when you are migrating a product to a new model, running a multi-model routing system, or standardizing safety behavior across an AI platform. The prompt takes your existing policy categories and target model conventions as input and produces a structured policy document with refusal triggers, safe alternative language, and boundary communication rules.

Do not use this prompt for a single-model deployment where a native safety policy is sufficient, or for generating the initial policy from scratch without defined categories. This prompt assumes you already have a set of refusal categories, harm taxonomies, or content policy documents that need to be translated into model-executable instructions. If you are starting from zero—with no existing policy categories, no defined harm types, and no refusal examples—you should first complete a policy authoring workflow before attempting cross-model portability. The prompt also assumes you have access to the target model's system instruction format and understand its instruction-following characteristics; without this context, the generated policy may not bind correctly.

The output of this prompt is a structured refusal policy specification, not a final system prompt ready for deployment. You should treat the generated specification as an intermediate artifact that requires human review, cross-model testing with your refusal consistency evals, and adaptation to your specific product context. The specification includes refusal triggers mapped to each policy category, safe alternative language templates, and boundary communication rules that tell the model what to say when a request falls into a gray area. After generating the specification, validate it against your golden refusal test cases, check for over-refusal on legitimate requests, and verify that the safe alternative language aligns with your product's tone and user experience goals.

This template is designed to be the single source for generating a refusal policy specification that can be ported across multiple model families. It takes your existing policy categories, safe alternative language, and boundary communication rules as input and produces a structured specification that maps each refusal category to the instruction format of your target models. Use this as the starting point for your policy portability pipeline.

markdownCopy
You are a refusal policy architect. Your task is to produce a refusal policy specification that can be adapted across multiple model providers while preserving consistent refusal behavior.

## INPUT DATA

### Current Refusal Policy
[POLICY_DOCUMENT]

### Refusal Categories
[REFUSAL_CATEGORIES]

### Safe Alternative Language
[SAFE_ALTERNATIVES]

### Boundary Communication Rules
[BOUNDARY_RULES]

### Target Models
[TARGET_MODELS]

### Risk Tolerance Level
[RISK_LEVEL]

## OUTPUT SCHEMA

Produce a JSON object with the following structure:

```json
{
  "policy_specification": {
    "version": "string",
    "last_updated": "ISO8601 timestamp",
    "refusal_categories": [
      {
        "category_id": "string",
        "category_name": "string",
        "description": "string",
        "trigger_conditions": ["string"],
        "refusal_template": "string",
        "safe_alternative_template": "string",
        "severity": "critical|high|medium|low",
        "requires_human_review": boolean,
        "model_specific_adaptations": {
          "[MODEL_NAME]": {
            "instruction_format": "string",
            "parsing_notes": "string",
            "known_sensitivity_flags": ["string"]
          }
        }
      }
    ],
    "boundary_communication": {
      "default_refusal": "string",
      "uncertainty_disclosure": "string",
      "escalation_path": "string"
    },
    "cross_model_consistency_checks": [
      {
        "check_id": "string",
        "description": "string",
        "test_input": "string",
        "expected_behavior": "string",
        "acceptable_variance": "string"
      }
    ]
  }
}

CONSTRAINTS

• Map every refusal category to each target model's instruction format.
• Include known sensitivity differences between models for each category.
• Define consistency checks that can be run as automated evals.
• Flag categories where model behavior is known to diverge significantly.
• Preserve the original policy intent; do not weaken or strengthen boundaries.
• For high-severity categories, require human review confirmation.

To adapt this template, replace each square-bracket placeholder with your actual policy data. The [POLICY_DOCUMENT] should contain your full current refusal policy text. [REFUSAL_CATEGORIES] should list each category of request you refuse, with examples. [SAFE_ALTERNATIVES] should contain the language you use to redirect users to acceptable alternatives. [BOUNDARY_RULES] should define how your system communicates its limitations. [TARGET_MODELS] should be a list of model identifiers you need to support. [RISK_LEVEL] should be set to low, medium, high, or critical to calibrate the conservatism of the generated specification.

After generating the specification, validate it by running the cross-model consistency checks against each target model. Pay special attention to categories flagged with known sensitivity differences. For high-severity refusal categories, always include a human review step before deploying the adapted instructions to production. Store the output as a versioned artifact in your policy repository alongside the evals that prove behavioral equivalence across models.

The refusal policy portability prompt is designed to be called programmatically as part of a policy migration pipeline, not as a one-off chat interaction. The application layer should treat this prompt as a policy compiler: it takes a source refusal policy and target model specifications as inputs, then produces a structured refusal specification that can be injected into the target model's system prompt. The harness must handle input validation, output parsing, cross-model consistency evaluation, and human review gates before the generated policy reaches production. This is a high-stakes workflow because refusal policy failures can expose users to harmful content or cause over-refusal that breaks core product functionality.

Integration pattern: Wrap the prompt in a service that accepts a source_policy (the refusal rules written for the original model), target_model (provider and model identifier), and target_model_conventions (instruction format, delimiter style, priority markers). The service should validate inputs against a schema—rejecting empty policies, unsupported target models, or missing convention fields—before constructing the prompt. After the model returns a response, parse the output against the expected refusal specification schema (categories, refusal language, safe alternatives, boundary communication). If parsing fails, retry once with a repair prompt that includes the parse error. Log every generation attempt, the parsed specification, and any validation failures for audit and debugging. For high-risk deployments, route the generated specification to a human review queue where a policy reviewer can approve, reject, or modify the output before it is deployed to production.

Cross-model consistency evaluation: The harness should include an automated evaluation step that tests the generated refusal policy against a golden set of test inputs spanning disallowed requests, borderline cases, and clearly allowed requests. Run these test inputs through the target model with the generated policy injected, then compare refusal decisions against expected outcomes. Track false-positive refusals (safe requests incorrectly refused), false-negative refusals (unsafe requests incorrectly allowed), and refusal style consistency (tone, safe alternative language). Set thresholds for each metric and block deployment if thresholds are exceeded. Store eval results alongside the generated policy for traceability. Model choice: Use a model with strong instruction-following for the generation step (GPT-4o, Claude 3.5 Sonnet) and the same target model for evaluation to ensure behavioral fidelity. Avoid using smaller or cheaper models for generation if refusal boundary precision is critical.

What to avoid: Do not deploy generated refusal policies without running the cross-model consistency eval suite. Do not assume that a policy that parses correctly will behave correctly—parsing success is not behavioral success. Do not skip human review for policies governing high-severity harm categories (CSAM, self-harm, violence). Do not use the same test inputs for generation and evaluation; maintain a held-out eval set. Finally, version every generated policy artifact with the source policy hash, target model, generation timestamp, and reviewer identity so that any production incident can be traced back to its origin.