Policy Reminder Insertion Prompt

This prompt is for AI engineers and product teams building multi-turn assistants that must enforce behavioral policies without creating unnecessary user friction. Its core job is to detect when a user request is approaching a defined policy boundary—such as a scope limitation, a compliance rule, or a data-handling restriction—and generate a preemptive, contextually appropriate reminder that prevents a violation before it occurs. The ideal user is someone integrating this into a production chat or copilot system where policy drift, over-refusal, or abrupt blocking would degrade the user experience.

Use this prompt when your assistant operates under a clear, documented policy contract and you need proactive enforcement rather than post-hoc refusal. It is designed for sessions where the policy has already been established in the system prompt or initial instructions, and the risk is that the policy will be forgotten or diluted over many turns. The prompt requires several inputs: the current user request [USER_REQUEST], the assistant's active behavioral policy [POLICY_DOCUMENT], recent conversation turns for context [CONVERSATION_HISTORY], and a defined [POLICY_BOUNDARY_MAP] that specifies which user intents or request types approach which policy limits. The output should be a structured decision: either a reminder object with the insertion text and timing guidance, or a no_action signal indicating the request is safely within bounds.

Do not use this prompt when the policy itself is ambiguous, unwritten, or still being defined—it cannot enforce what it cannot reference. It is also inappropriate for single-turn interactions where there is no risk of context-window drift, or for systems where a hard refusal is the only acceptable response to a boundary violation. Avoid deploying this as a standalone guard; it should be paired with a downstream validation step, such as the Output Contract Validation Prompt or the Compliance Boundary Re-Statement Prompt, to confirm that the reminder was both inserted and effective. In high-risk regulated domains, always route the generated reminder through a human review queue before it reaches the user.

The Policy Reminder Insertion Prompt is designed to sit between the user's latest turn and the assistant's response generation. It evaluates whether the user's request is approaching a defined policy boundary and, if so, generates a preemptive reminder that prevents violation without unnecessary friction. The template uses square-bracket placeholders for all variable inputs, making it straightforward to adapt across different policy domains, risk levels, and assistant personas.

textCopy
SYSTEM: You are a policy guard module for an AI assistant. Your job is to detect when a user request is approaching a policy boundary and insert a contextually appropriate reminder before the assistant responds. You do not generate the final response. You only decide whether a reminder is needed and, if so, what it should say.

## POLICY DEFINITIONS
[POLICIES]

## CURRENT CONVERSATION CONTEXT
[CONVERSATION_HISTORY]

## LATEST USER REQUEST
[USER_REQUEST]

## RISK LEVEL
[RISK_LEVEL]

## REMINDER INSERTION RULES
- Insert a reminder only when the user request is within [PROXIMITY_THRESHOLD] of violating a defined policy.
- If the request is clearly compliant, return NO_REMINDER.
- If the request is an explicit violation, return VIOLATION_ESCALATE instead of a reminder.
- Reminders must be concise, specific to the policy at risk, and phrased in [TONE_STYLE].
- Never insert a reminder that contradicts or overrides the assistant's core behavioral contract.
- If multiple policies are at risk, prioritize by [PRIORITY_ORDER].

## OUTPUT FORMAT
Return a JSON object with exactly this schema:
{
  "decision": "REMINDER | NO_REMINDER | VIOLATION_ESCALATE",
  "policy_id": "string or null",
  "reminder_text": "string or null",
  "proximity_score": 0.0-1.0,
  "rationale": "brief explanation of why this decision was made"
}

## EXAMPLES
[EXAMPLES]

## CONSTRAINTS
[CONSTRAINTS]

To adapt this template, replace each square-bracket placeholder with concrete values. [POLICIES] should contain the full text of each policy the assistant must enforce, including its ID, boundary conditions, and violation criteria. [CONVERSATION_HISTORY] should include the last N turns formatted consistently with how your application passes context to the model. [PROXIMITY_THRESHOLD] defines how close a request must be to a boundary before triggering a reminder—set this conservatively for regulated domains and more permissively for low-risk assistants. [TONE_STYLE] controls whether reminders sound firm, helpful, or neutral. [PRIORITY_ORDER] resolves conflicts when a single request brushes against multiple policies simultaneously.

Before deploying, validate the prompt against a golden set of user requests that span clearly compliant, borderline, and clearly violating cases. Measure both precision (reminders only when needed) and recall (no missed boundary approaches). In high-risk domains, route VIOLATION_ESCALATE decisions to a human review queue rather than blocking the user automatically. The proximity_score field enables downstream logic to apply different treatments based on how close the request is to the boundary—for example, a soft nudge at 0.6 versus a firm restatement at 0.9.

The Policy Reminder Insertion Prompt is not a standalone chat interaction—it is a middleware component that sits between the user's latest message and the assistant's response generation. In production, you should invoke this prompt as a pre-generation check whenever the user's intent approaches a known policy boundary. The prompt expects a structured input containing the user's current request, the relevant policy text, and the conversation's recent history. Its output is a decision object: either insert_reminder with the reminder text and insertion point, or no_action with a confidence score. This decision must be consumed by your application's orchestration layer before the main assistant prompt is called.

Wire the prompt into your application as a lightweight classifier step. Use a fast, cost-effective model (such as GPT-4o-mini or Claude Haiku) for this check, since it runs on every turn where a policy boundary is in play. The application should call this prompt with a structured JSON input containing [USER_REQUEST], [POLICY_TEXT], [CONVERSATION_HISTORY], and [POLICY_BOUNDARY_DISTANCE] (a numeric score from your upstream intent classifier indicating how close the user is to a violation). Parse the output strictly: if action is insert_reminder, prepend the reminder_text to the assistant's response context before calling the main generation model. If action is no_action but confidence is below your threshold (we recommend 0.85), log the turn for human review and consider escalating to a confirmation gate. Always validate the output schema before acting on it—reject malformed JSON and retry once with a stricter schema instruction before falling back to a conservative default (insert a generic policy reminder).

Log every invocation with the input context, the model's decision, the confidence score, and whether the reminder was actually inserted. This audit trail is critical for policy compliance teams and for tuning the boundary distance threshold over time. In regulated domains, require human review for any turn where the prompt's confidence score falls below 0.9 or where the policy_boundary_distance score is ambiguous (between 0.4 and 0.6 on a 0–1 scale). Do not use this prompt as the sole enforcement mechanism for safety-critical policies—it is a reminder layer, not a hard block. The downstream assistant prompt must still contain the full policy text and refusal instructions. Test the prompt against a golden dataset of boundary-approaching requests, including adversarial examples where users attempt to circumvent policies through indirect language, to calibrate your distance thresholds before production deployment.