Role Boundary Reinforcement Prompt

This prompt is for AI engineers and product teams who need to prevent assistant role creep in production. The core job-to-be-done is detecting when a user request or the assistant's own response is beginning to exceed the defined role scope, and generating a boundary reinforcement statement that re-anchors the assistant to its authorized functions. Use this when you have a copilot, support agent, or domain-constrained assistant that must stay within a strict functional boundary—such as a tax assistant that should not give legal advice, a coding assistant that should not opine on architecture decisions outside its scope, or a customer support bot that should not make pricing promises. The ideal user is a developer or prompt engineer integrating this check into a multi-turn orchestration layer.

Do not use this prompt when the assistant's role is intentionally broad, when the user is expected to explore adjacent topics freely, or when the cost of a false-positive boundary reinforcement is higher than the risk of mild scope drift. This prompt is also inappropriate for single-turn workflows where there is no accumulated conversation state to drift from. The boundary reinforcement statement it generates is designed to be polite and workflow-preserving, not a hard refusal—if you need a strict refusal or escalation, pair this with a Confirmation Gate Prompt or an Off-Topic Guardrail Enforcement Prompt instead. Required context includes the assistant's defined role description, the conversation history showing the drift, and the specific turn that triggered the check.

Before deploying this prompt, define what 'in-role' means for your assistant with concrete examples of both allowed and disallowed requests. Write eval cases that include subtle boundary violations—users asking for adjacent-domain help, requests that sound in-role but require out-of-scope actions, and gradual topic shifts that accumulate into role creep over several turns. The prompt works best as a mid-session check triggered by a classifier or policy engine, not as a system-level instruction that fires on every turn. Wire it into your orchestration layer so the reinforcement statement is injected into the conversation only when a boundary is actually being approached, not as a constant overhead that wastes context budget and annoys users.

This prompt template is designed to be inserted into a multi-turn assistant pipeline whenever a user request or the assistant's own draft response risks exceeding the defined role scope. It takes the original role definition, the recent conversation context, and the concerning turn as inputs, then produces a boundary reinforcement statement that the assistant can use to re-anchor itself. The template uses square-bracket placeholders for all dynamic inputs so you can wire it directly into your prompt assembly logic without modification.

textCopy
SYSTEM: You are a role boundary enforcement module. Your job is to detect when a user request or an assistant's draft response exceeds the assistant's defined role scope, and to generate a concise boundary reinforcement statement that re-anchors the assistant to its authorized functions.

ASSISTANT ROLE DEFINITION:
[ROLE_DEFINITION]

SCOPE BOUNDARIES:
- Authorized functions: [AUTHORIZED_FUNCTIONS]
- Explicitly out-of-scope: [OUT_OF_SCOPE_FUNCTIONS]
- Boundary conditions: [BOUNDARY_CONDITIONS]

RECENT CONVERSATION CONTEXT (last N turns):
[CONVERSATION_HISTORY]

CURRENT TURN:
User request: [USER_REQUEST]
Assistant draft response (if any): [DRAFT_RESPONSE]

TASK:
1. Analyze whether the user request or assistant draft response exceeds the defined role scope.
2. If no boundary violation is detected, respond with: {"violation_detected": false, "boundary_statement": null, "violation_detail": null}
3. If a boundary violation is detected, respond with a JSON object containing:
   - violation_detected: true
   - violation_type: one of ["user_request_out_of_scope", "assistant_draft_out_of_scope", "both"]
   - violated_boundary: which specific boundary from the scope definition was crossed
   - violation_detail: a brief, factual description of what crossed the boundary and why
   - boundary_statement: a concise, polite statement (1-3 sentences) that the assistant should use to re-anchor the conversation. The statement must:
     * Acknowledge what the user asked for or what the assistant started to do
     * Clearly state the scope limitation without apologizing excessively
     * Offer a constructive alternative within scope if one exists
     * Maintain a helpful, professional tone
   - severity: one of ["low", "medium", "high"] based on how far the request exceeds scope

CONSTRAINTS:
- Do not fabricate capabilities the assistant does not have.
- Do not use the boundary statement to lecture or scold the user.
- If the violation is low severity and a reasonable in-scope alternative exists, prioritize redirection over refusal.
- If the violation is high severity (safety, legal, regulated domain), the boundary statement must be firm and unambiguous.
- The boundary statement must be ready for the assistant to use verbatim in the conversation.

OUTPUT FORMAT: Valid JSON only. No markdown, no commentary outside the JSON object.

To adapt this template for your application, replace each square-bracket placeholder with values from your prompt assembly pipeline. [ROLE_DEFINITION] should contain the full system-level role description your assistant operates under. [AUTHORIZED_FUNCTIONS] and [OUT_OF_SCOPE_FUNCTIONS] should be explicit lists derived from your product's capability boundaries. [CONVERSATION_HISTORY] should include the last 3-5 turns to provide enough context for the boundary check without consuming excessive tokens. Wire the output boundary_statement directly into the assistant's next response when violation_detected is true. For high-severity violations, consider escalating to a human review queue instead of relying solely on the generated statement.

The Role Boundary Reinforcement Prompt is not a standalone chat instruction; it is a guardrail component that should be wired into your assistant's execution loop as a pre-response check. The most reliable pattern is to run this prompt as a secondary model call immediately before the assistant's final response is returned to the user. When the user's request or the assistant's draft response triggers a boundary violation, the reinforcement statement generated by this prompt is prepended to the assistant's output, re-anchoring the conversation to the defined role scope. This architecture keeps the primary assistant prompt focused on task execution while the boundary check operates as a separate, auditable control layer.

For production implementation, wrap the prompt in a lightweight service function that accepts the current conversation history, the assistant's draft response, and the defined role boundary document as inputs. The function should return a structured decision object with three fields: boundary_violated (boolean), reinforcement_statement (string or null), and violation_severity (enum: none, soft, hard). On a soft violation, prepend the reinforcement statement and log the event. On a hard violation—such as a user requesting medical advice from a customer support bot—block the original response entirely, return only the reinforcement statement, and optionally escalate to a human review queue. Use a fast, cost-efficient model for this check (e.g., GPT-4o-mini, Claude Haiku) since it runs on every turn. Implement a short timeout (under 2 seconds) and a fallback: if the boundary check call fails, log the failure and either pass the response through with a warning flag or block it based on your risk tolerance.

Validation and testing are critical because boundary misclassification erodes trust in both directions. Build an eval suite with three categories of test cases: clear in-scope requests that must pass without triggering a violation, clear out-of-scope requests that must trigger a reinforcement statement, and ambiguous edge cases where you define the expected behavior. For each test case, validate not only the boundary_violated boolean but also the tone of the reinforcement statement—it should redirect without sounding punitive. In regulated domains, route all hard violations to a human review dashboard where an operator can approve, modify, or override the reinforcement statement before it reaches the user. Log every boundary check decision with the conversation ID, the draft response, the violation severity, and the reinforcement statement for audit and prompt improvement cycles. The next step is to tune your role boundary document: if you see high false-positive rates, your boundary definition is too restrictive; if violations slip through, it is too permissive.