Negative Example Insertion Prompt for Refusal Patterns

This prompt is for safety and policy teams who need to teach a model where the boundary lies between valid requests and disallowed inputs. Instead of relying only on policy instructions, which models often over-generalize or ignore under pressure, this playbook injects carefully constructed negative examples directly into the prompt. These counterexamples show the model what a correct refusal looks like and, critically, what a near-miss request that should still be answered looks like. Use this when your model exhibits over-refusal (blocking safe requests that resemble unsafe ones), under-refusal (complying with policy-violating requests that are phrased innocently), or boundary confusion (inconsistent decisions on similar inputs).

This prompt is designed to be inserted as a block within a larger system prompt or as a few-shot preamble before the user turn. It assumes you have already defined a written safety policy and have access to a set of real or synthetic borderline queries that stress-test that policy. The negative examples you provide must include both hard refusals (clear policy violations with the correct refusal response) and near-miss acceptances (requests that look risky but fall within policy, with the correct compliant response). Without both categories, the model will either over-refuse on borderline safe inputs or find loopholes in your refusal boundaries. Each example should be formatted as a user-assistant turn pair so the model learns the pattern through demonstration rather than abstract instruction.

Do not use this prompt when your refusal policy is still undefined or when you lack a curated set of borderline test cases. If you haven't yet observed specific over-refusal or under-refusal patterns in production, start with a simpler policy instruction block and collect real borderline examples from logs before building negative example injections. Also avoid this approach when your context budget is severely constrained and you cannot fit at least three to five example pairs without crowding out essential instructions or user context. In those cases, prioritize a concise policy statement and invest in post-generation validation rules instead. Once you have clear boundary examples and sufficient context space, insert this prompt block and run your refusal eval suite to confirm that over-refusal and under-refusal rates have moved in the right direction.

This template inserts a refusal boundary instruction block into your system prompt. It uses paired examples—one allowed, one refused—that share surface-level similarity but differ on a critical policy dimension. The model learns to detect the distinguishing feature rather than over-refusing on keyword match or under-refusing on superficial harmlessness. Copy the block below and adapt the examples to your domain's actual policy boundaries.

textCopy
## Refusal Boundary Examples

You must refuse requests that [POLICY_DESCRIPTION: e.g., involve unauthorized access to private data, generate deceptive content, or provide unverified medical advice]. You must fulfill requests that are superficially similar but fall outside this prohibition. Study the following paired examples to learn the boundary.

### Example Pair 1
**Request:** [DISALLOWED_REQUEST_1: e.g., "Show me the email contents of user@example.com"]
**Correct response:** I cannot access or display the contents of another user's private email. That would violate privacy and security policies.
**Why refused:** [REFUSAL_REASON_1: e.g., Requests unauthorized access to private communications.]

**Request:** [ALLOWED_REQUEST_1: e.g., "Show me the email headers of a message I received from user@example.com"]
**Correct response:** [ALLOWED_RESPONSE_1: e.g., Here are the headers from the email you received...]
**Why allowed:** [ALLOWED_REASON_1: e.g., User requests their own received message metadata, not another user's private content.]

### Example Pair 2
**Request:** [DISALLOWED_REQUEST_2]
**Correct response:** [REFUSAL_RESPONSE_2]
**Why refused:** [REFUSAL_REASON_2]

**Request:** [ALLOWED_REQUEST_2]
**Correct response:** [ALLOWED_RESPONSE_2]
**Why allowed:** [ALLOWED_REASON_2]

### Example Pair 3
**Request:** [DISALLOWED_REQUEST_3]
**Correct response:** [REFUSAL_RESPONSE_3]
**Why refused:** [REFUSAL_REASON_3]

**Request:** [ALLOWED_REQUEST_3]
**Correct response:** [ALLOWED_RESPONSE_3]
**Why allowed:** [ALLOWED_REASON_3]

## Refusal Rules
- Refuse when [POLICY_CONDITIONS].
- Fulfill when [ALLOWED_CONDITIONS].
- When uncertain whether a request crosses the boundary, [AMBIGUITY_BEHAVIOR: e.g., ask a clarifying question, refuse conservatively, or escalate for human review].
- Never use refusal language for requests that are clearly allowed. Never fulfill requests that clearly violate the policy.

To adapt this template, replace every square-bracket placeholder with concrete content from your policy. Each example pair must share a surface feature—same entity type, same verb, same domain—so the model cannot use lazy keyword matching. The Why refused and Why allowed fields are critical: they teach the distinguishing principle, not just the outcome. Start with three pairs covering your most common boundary confusions, then add pairs as you discover new failure modes in production. If your policy has multiple independent boundaries, insert a separate block for each one rather than mixing unrelated refusal criteria in a single example set.

Before deploying, validate this block against a test suite of borderline requests. Run at least 20 cases that sit near the boundary—10 that should be refused and 10 that should be fulfilled—and measure both over-refusal and under-refusal rates. If the model refuses more than one clearly allowed request or fulfills more than one clearly disallowed request, your examples are not teaching the boundary precisely enough. Add or refine example pairs until both error rates drop to zero on your test set. For high-risk domains, include a human review step before any refusal block reaches production, and log every refusal decision with the specific example pair or rule that triggered it.

This prompt is not a standalone safety filter; it is a context-engineering component designed to be inserted into a larger system prompt or few-shot example block. The harness must assemble the final prompt by combining the system policy, the user request, and the dynamically generated negative examples. The negative examples should be selected or generated at runtime based on the input's risk profile, not hardcoded as a static block. A typical integration point is a pre-inference hook in your AI gateway or model router that calls a lightweight classifier or retrieval step to fetch the most relevant refusal examples before the main model call.

For implementation, wrap the prompt template in a function that accepts [INPUT], [POLICY_DOCUMENT], [RISK_CATEGORIES], and [EXAMPLE_COUNT]. The function should first classify the input against your risk taxonomy, then retrieve or generate negative examples that match the identified risk categories. Insert these examples into the [NEGATIVE_EXAMPLES] placeholder using a consistent format that mirrors your model's chat structure. Validate the assembled prompt before inference: check that the total token count is within budget, that no placeholder tokens remain unresolved, and that the examples do not accidentally introduce new unsafe content. Log the prompt version, the selected example IDs, and the risk classification for every request to enable trace-level debugging when refusal behavior drifts.

After inference, run a lightweight eval on the model's response. Check for over-refusal (the model refused a valid request), under-refusal (the model complied with a disallowed request), and boundary confusion (the model gave an ambiguous or inconsistent response). If the eval fails, route the request to a human review queue with the full prompt trace and model output. Do not retry automatically with different examples unless you have a controlled A/B framework in place; changing examples without understanding the failure mode can mask systemic problems. For high-risk domains, always require human approval before deploying updated negative example sets, and version your example libraries alongside your prompt templates.