Negative Example Injection for Safety Prompt

This prompt is for safety engineers and prompt authors constructing training data or system instructions that must teach a model what not to do. Use it when you need to inject negative examples that demonstrate format violations, policy breaches, unsafe completions, or refusal failures. This is not a general-purpose instruction prompt. It is a structured injection template that pairs positive demonstrations with explicit negative counterexamples, giving the model a clear signal about which outputs are unacceptable. Use this when instruction-only safety policies produce inconsistent refusal behavior, when models comply with subtly dangerous requests, or when you need to harden a safety boundary without fine-tuning.

The ideal user has already written a safety policy or behavioral instruction set and observed failures in production or red-teaming. You have concrete examples of the model complying with requests it should have refused, or refusing requests it should have allowed. You need to inject those failures back into the prompt as explicit negative demonstrations. This prompt template expects you to supply both the dangerous or non-compliant output the model produced and the correct refusal or safe alternative it should have produced. The template structures these pairs so the model learns the boundary, not just a single rule. You should also have a validation set of edge cases ready to test whether the injection narrowed the boundary correctly without causing over-refusal on legitimate requests.

Do not use this prompt when you lack concrete failure examples. Negative example injection is a surgical tool, not a first resort. If you are writing a safety policy for the first time, start with clear instruction-only policies and evaluate them against a broad test set before injecting negative examples. Do not use this prompt when the failure mode is ambiguous or when you cannot articulate why a specific output was wrong—vague negative examples confuse the model more than they help. Do not use this prompt as a substitute for fine-tuning when the safety boundary requires hundreds of examples to learn; at that scale, supervised fine-tuning on refusal data is more reliable and cost-effective. Finally, do not use this prompt without a regression test suite that includes both legitimate requests (to detect over-refusal) and dangerous requests (to detect compliance failures). Negative example injection can silently shift the refusal boundary in unexpected ways, and you need evals to catch that drift before it reaches users.

This template provides a structured way to inject negative examples—demonstrations of incorrect, unsafe, or policy-violating behavior—directly into your safety prompt. Unlike positive examples that show the model what to do, negative examples explicitly mark behaviors to avoid. This is critical for safety engineering because models often over-generalize from positive examples alone, leading to dangerous compliance with subtly harmful requests. The template uses square-bracket placeholders that you replace with your specific safety policy, example pairs, and output requirements before deployment.

textCopy
You are an AI assistant operating under a strict safety policy. Your responses must comply with the policy below and avoid the negative behaviors demonstrated in the examples.

## SAFETY POLICY
[SAFETY_POLICY]

## NEGATIVE EXAMPLES
Below are examples of INCORRECT responses that violate the safety policy. You must NOT produce responses like these. Each example shows a user request followed by a BAD response that you should avoid.

### Negative Example 1
**User Request:** [NEG_EXAMPLE_1_REQUEST]
**BAD Response (DO NOT DO THIS):** [NEG_EXAMPLE_1_BAD_RESPONSE]
**Why This Is Wrong:** [NEG_EXAMPLE_1_EXPLANATION]

### Negative Example 2
**User Request:** [NEG_EXAMPLE_2_REQUEST]
**BAD Response (DO NOT DO THIS):** [NEG_EXAMPLE_2_BAD_RESPONSE]
**Why This Is Wrong:** [NEG_EXAMPLE_2_EXPLANATION]

### Negative Example 3
**User Request:** [NEG_EXAMPLE_3_REQUEST]
**BAD Response (DO NOT DO THIS):** [NEG_EXAMPLE_3_BAD_RESPONSE]
**Why This Is Wrong:** [NEG_EXAMPLE_3_EXPLANATION]

[ADDITIONAL_NEGATIVE_EXAMPLES]

## POSITIVE EXAMPLES
For contrast, here are examples of CORRECT responses that comply with the safety policy.

### Positive Example 1
**User Request:** [POS_EXAMPLE_1_REQUEST]
**CORRECT Response:** [POS_EXAMPLE_1_CORRECT_RESPONSE]

### Positive Example 2
**User Request:** [POS_EXAMPLE_2_REQUEST]
**CORRECT Response:** [POS_EXAMPLE_2_CORRECT_RESPONSE]

[ADDITIONAL_POSITIVE_EXAMPLES]

## OUTPUT REQUIREMENTS
[OUTPUT_REQUIREMENTS]

## CURRENT REQUEST
**User Request:** [USER_INPUT]

Generate a response that complies with the safety policy, avoids all negative example patterns, and follows the output requirements.

When adapting this template, start by defining your [SAFETY_POLICY] with concrete, testable rules rather than vague principles. Each negative example must include three components: the user request that triggered the bad behavior, the specific bad response to avoid, and a clear explanation of why it violates policy. The explanation is essential—it teaches the model the reasoning behind the refusal, not just the surface pattern. For high-risk domains, include at least five negative examples covering different failure modes: format violations, policy breaches, dangerous compliance, over-refusal, and edge-case ambiguity. Pair each negative example with a corresponding positive example that shows the correct behavior for a similar request, creating a clear contrast boundary. Before deploying, run the prompt through an evaluation harness that tests whether the model reproduces any negative example patterns when given paraphrased versions of the negative example requests.

The negative example injection prompt is not a standalone safety solution—it is a data generation and policy teaching component that must be embedded in a broader safety harness. In production, this prompt typically runs offline or in a CI/CD pipeline to produce training examples, evaluation test cases, or policy clarification samples. It should never be exposed directly to end users or used as a runtime safety classifier. Instead, treat its output as candidate safety training data that requires validation before it influences model behavior in production. The harness must enforce schema compliance, content safety of the generated negative examples themselves, and alignment with your current safety policy version.

Wire the prompt into an application by first defining the input contract: [POLICY_DESCRIPTION], [HARM_CATEGORY], [REFUSAL_STYLE], and [NUM_EXAMPLES] are required fields. Validate inputs before calling the model—reject empty policies, undefined harm categories, or example counts that exceed your review capacity. After generation, apply a multi-stage validation pipeline: (1) schema validation to ensure each example contains user_request, incorrect_response, correct_refusal, and policy_violation_reason fields; (2) content safety screening using a separate classifier or keyword blocklist to confirm the generated incorrect_response examples do not themselves contain harmful content that could leak into training data; (3) policy alignment check comparing the policy_violation_reason against your current policy document to detect drift. Log every generation run with the prompt version, model version, input parameters, raw output, validation results, and reviewer identity. For high-risk safety domains, require human review of all generated negative examples before they enter any training or evaluation dataset. Use a review queue that surfaces examples with low confidence scores, borderline policy violations, or format anomalies first.

Model choice matters here. Use a model with strong instruction-following and safety awareness for generation—frontier models typically produce more nuanced negative examples than smaller models. However, be aware that the same model used for generation may later be fine-tuned on these examples, creating potential for subtle self-reinforcement of blind spots. Mitigate this by rotating generation models, cross-validating with a different model family, or maintaining a holdout set of human-authored negative examples for comparison. For monitoring, track the refusal rate on your production safety eval set before and after incorporating generated examples. A sudden drop in refusal rate on known dangerous inputs indicates the negative examples were ineffective or incorrectly formatted. A spike in refusal rate on benign inputs suggests the examples were too broad or ambiguous. Implement a rollback mechanism that can revert to the previous example set if either metric crosses a predefined threshold. Finally, version your negative example sets alongside your safety policy and prompt template—when the policy changes, regenerate and revalidate the entire example set rather than patching individual examples.