Compliance Boundary Re-Statement Prompt

This prompt is for AI engineers and product teams building regulated industry assistants—such as those in finance, healthcare, or legal services—that must periodically remind users of their operational boundaries. The job-to-be-done is generating a contextually appropriate, non-disruptive re-statement of compliance limits, data handling policies, or scope restrictions when a conversation drifts toward a boundary. The ideal user is a developer integrating this into a multi-turn chat harness where policy drift or user overreach is a known production risk. You need a defined system policy contract, the recent conversation history, and a trigger signal indicating a boundary is being approached.

Do not use this prompt for general-purpose chatbots, creative writing assistants, or any system where strict operational boundaries are not legally or contractually required. It is not a replacement for hard-coded guardrails, tool-use authorization checks, or human review workflows. This prompt is specifically for the re-statement of existing policies, not for defining new ones or making compliance decisions. It assumes the underlying policy document is already authored and approved. If your assistant's context window is too small to hold both the full policy and the conversation, pair this with a prompt compression or instruction re-injection strategy from the Context Window Budgeting pillar.

Before implementing, ensure you have a clear trigger mechanism—such as a classification router detecting off-topic queries or a keyword-based boundary detector—to invoke this prompt only when needed. Over-use will annoy users and waste context budget; under-use risks compliance violations. The output should be treated as a draft for a human reviewer if the domain is high-risk. Wire the generated re-statement into your application's response stream, log it for audit purposes, and monitor whether users respect the boundary or attempt to circumvent it, which should trigger an escalation workflow.

This template produces a compliance boundary re-statement that reminds the user of operational limits, data handling policies, or scope restrictions. The prompt is designed to be called by an application-level detector that identifies when a conversation turn is approaching a defined boundary. It generates a re-statement that is contextually appropriate to the current conversation rather than a generic disclaimer, balancing compliance clarity with conversational flow. The template uses square-bracket placeholders that your application must populate before sending the request to the model.

codeCopy
You are a compliance-aware assistant operating in a regulated domain. Your task is to generate a contextually appropriate re-statement of operational boundaries when a user request approaches a defined compliance limit.

## CONVERSATION CONTEXT
[CONVERSATION_HISTORY]

## CURRENT USER REQUEST
[USER_REQUEST]

## BOUNDARY BEING APPROACHED
- Boundary name: [BOUNDARY_NAME]
- Boundary description: [BOUNDARY_DESCRIPTION]
- Policy reference: [POLICY_REFERENCE]
- Risk level: [RISK_LEVEL]

## RE-STATEMENT PARAMETERS
- Timing: [TIMING_CONTEXT]
- Tone: [TONE_REQUIREMENT]
- Required elements: [REQUIRED_ELEMENTS]
- Prohibited language: [PROHIBITED_LANGUAGE]

## OUTPUT INSTRUCTIONS
Generate a compliance boundary re-statement that:
1. Acknowledges the user's request without dismissing it.
2. Clearly states the boundary in plain, non-legalistic language.
3. Explains why the boundary exists, referencing [POLICY_REFERENCE] when appropriate.
4. Offers a permitted alternative or next step if one exists.
5. Uses the specified tone: [TONE_REQUIREMENT].
6. Avoids the following prohibited language: [PROHIBITED_LANGUAGE].
7. Does not apologize excessively or suggest the boundary is negotiable.

## OUTPUT FORMAT
Return a JSON object with these fields:
{
  "boundary_restatement": "The full re-statement text to insert into the conversation.",
  "boundary_type": "[BOUNDARY_NAME]",
  "risk_level": "[RISK_LEVEL]",
  "alternative_offered": true or false,
  "alternative_description": "Brief description of the alternative offered, or null if none.",
  "requires_escalation": true or false,
  "escalation_reason": "Reason for escalation, or null if not required."
}

## CONSTRAINTS
- Do not fabricate policy details. Only reference [POLICY_REFERENCE] as provided.
- Do not use language that implies the boundary is flexible or can be waived.
- Do not generate legal advice or interpret regulations beyond the stated boundary.
- If [RISK_LEVEL] is "high", the re-statement must include an explicit statement that the action cannot be performed.
- Keep the re-statement under [MAX_TOKENS] tokens.

To adapt this template, your application must populate each placeholder before calling the model. The [CONVERSATION_HISTORY] should include enough prior turns for the model to understand the conversational context without exceeding your context budget. The [TIMING_CONTEXT] field should describe where in the conversation this re-statement will appear—such as "immediately before the assistant's response to the current turn" or "as a standalone message before continuing." The [REQUIRED_ELEMENTS] field should enumerate the specific compliance points that must appear, such as "data retention policy," "scope of authorized advice," or "jurisdictional limitation." The [PROHIBITED_LANGUAGE] field should list phrases that must not appear, such as "I'm not a lawyer" or hedging language that undermines the boundary.

Before deploying this prompt, validate that your boundary detection logic is triggering at the correct proximity to the boundary—neither too early, which creates unnecessary friction, nor too late, which risks a compliance violation. Test the prompt against edge cases where the user pushes back against the re-statement, where multiple boundaries are approached simultaneously, and where the conversation history contains prior boundary discussions that could confuse the model. For high-risk domains, route the generated re-statement through a human review queue before it reaches the user, and log every re-statement event with the boundary name, risk level, and whether an alternative was offered for audit purposes.

The Compliance Boundary Re-Statement Prompt is not a standalone chat instruction—it is a mid-session intervention that must be triggered by application logic, not by the model deciding on its own. The harness should monitor conversation state for boundary-proximity signals: a user asking about data retention, requesting an action outside the assistant's scope, or using language that suggests they may misunderstand the assistant's limitations. When a boundary-proximity event fires, the harness injects this prompt into the context window with the current conversation summary, the specific boundary being approached, and the required re-statement phrasing controls. The model then generates a re-statement that the harness validates before surfacing to the user.

Wire the prompt into your application with a boundary-proximity detector that runs before each assistant response. This detector can be a lightweight classifier prompt, a keyword-trigger list, or a vector similarity check against known boundary-violation patterns. When proximity exceeds a configurable threshold, the harness calls the Compliance Boundary Re-Statement Prompt with these inputs: [CONVERSATION_SUMMARY] (last N turns compressed), [BOUNDARY_TYPE] (e.g., data_handling, scope_restriction, regulatory_limit), [BOUNDARY_POLICY_TEXT] (the exact policy language to re-state), [PHRASING_STYLE] (e.g., preemptive_gentle, corrective_firm, informational_neutral), and [TIMING_CONTEXT] (whether this is a first reminder, a repeated boundary approach, or an escalation). The output must conform to a strict schema: { re_statement_text: string, boundary_cited: string, phrasing_style_used: string, escalation_flag: boolean }. Validate this schema before the re-statement reaches the user. If validation fails, retry once with the validation error injected into the prompt as [PREVIOUS_OUTPUT_ERROR]. If the retry also fails, fall back to a pre-approved static re-statement from your policy library and log the failure for review.

Model choice matters here. This prompt requires instruction-following precision over creative fluency. Use a model with strong schema adherence (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 to maximize output determinism. Do not use a small or quantized model for this task unless you have validated re-statement accuracy against a golden dataset of 50+ boundary scenarios. Log every re-statement event with the boundary-proximity score that triggered it, the generated re-statement, the validation result, and whether the fallback was used. These logs become your audit trail for compliance reviewers. For high-risk domains (healthcare, finance, legal), route all re-statements to a human review queue for the first 100 production events, then sample-review thereafter. Never let the model decide whether to re-state a boundary—that decision must stay in application code with auditable triggers.