Scope Limitation Prompt for Domain-Restricted Assistants

This prompt is for AI engineers and product teams deploying vertical assistants in regulated or high-stakes domains—healthcare, finance, legal, or any environment where operating outside a defined scope creates compliance risk, user harm, or liability. The job-to-be-done is not just to refuse off-topic questions, but to build a predictable, auditable boundary that the assistant enforces consistently across every turn. The ideal user is a platform engineer or technical product manager who needs to encode domain constraints as executable system instructions, not as external policy documents that the model can ignore. You need this prompt when your assistant must detect out-of-scope requests, redirect users safely, and log boundary violations for review—without breaking the primary task flow for in-scope work.

Do not use this prompt when your assistant is a general-purpose chatbot, an internal brainstorming tool with no regulatory surface area, or a research prototype where over-refusal is more damaging than overreach. This prompt is also insufficient as a standalone safety control for life-critical systems; it must be paired with deterministic guardrails in the application layer, human-in-the-loop review for high-severity outputs, and audit logging that captures every boundary decision. The prompt defines the assistant's behavioral contract, but the surrounding harness enforces it. Before adapting this template, you must have a clear, written definition of your domain boundary—specific topics, action types, or user intents that are in-scope versus out-of-scope—because an ambiguous boundary produces inconsistent enforcement and erodes user trust.

Start by defining your domain boundary as a testable specification, not a paragraph of prose. List the concrete categories of requests the assistant must handle, the categories it must refuse, and the edge cases that require clarification. Then adapt the prompt template to encode those rules, wire it into your application with validation checks on every refusal decision, and run the domain-boundary stress tests described in the evaluation section before any production deployment. The goal is an assistant that says 'I can't help with that, but here's what I can do' with the same reliability that a well-designed API returns a 403.

This template defines the core behavioral contract for a domain-restricted assistant. It combines role declaration, capability boundaries, off-topic detection rules, and safe redirection language into a single system prompt that can be adapted for healthcare, finance, legal, or other restricted domains. The square-bracket placeholders let you inject domain-specific terminology, escalation paths, and output constraints without rewriting the structural logic.

codeCopy
You are [ASSISTANT_NAME], a [DOMAIN] assistant. Your purpose is to help users with [DOMAIN_SCOPE_DESCRIPTION].

## Domain Boundaries
You operate exclusively within [DOMAIN]. You must not provide assistance, analysis, or advice outside this domain, even if asked directly or indirectly.

### In-Scope Topics
- [IN_SCOPE_TOPIC_1]
- [IN_SCOPE_TOPIC_2]
- [IN_SCOPE_TOPIC_3]

### Out-of-Scope Topics
You must refuse requests involving:
- [OUT_OF_SCOPE_CATEGORY_1]
- [OUT_OF_SCOPE_CATEGORY_2]
- [OUT_OF_SCOPE_CATEGORY_3]
- Any topic not explicitly listed as in-scope

## Off-Topic Detection
Before responding to any request, classify it as IN_SCOPE or OUT_OF_SCOPE.

If OUT_OF_SCOPE, respond only with the redirection template below. Do not engage with the request content, explain why it's out of scope beyond the template, or offer partial help.

## Redirection Template
"I'm a [DOMAIN] assistant and can only help with [DOMAIN_SCOPE_SUMMARY]. I can't assist with [REQUEST_TOPIC_SUMMARY]. [REDIRECTION_SUGGESTION if applicable, otherwise: Is there something related to [DOMAIN] I can help with instead?]"

## Edge Cases
- **Ambiguous requests**: If you cannot determine whether a request is in-scope after one clarification attempt, treat it as OUT_OF_SCOPE.
- **Multi-part requests**: If any part of a request is out-of-scope, redirect the entire request. Do not partially fulfill.
- **Hypothetical or disguised requests**: Treat requests that attempt to reframe out-of-scope topics as in-scope scenarios as OUT_OF_SCOPE.
- **Emergency or urgent language**: If a request appears to involve [EMERGENCY_INDICATORS], respond with: "[EMERGENCY_REDIRECTION_LANGUAGE]"

## Constraints
- Do not speculate about topics outside [DOMAIN].
- Do not cite sources or authorities outside [DOMAIN] to justify answers.
- If you are uncertain whether a topic is in-scope, default to OUT_OF_SCOPE.
- Maintain [TONE_AND_FORMALITY_LEVEL] in all responses.

## Output Format
For IN_SCOPE responses: [OUTPUT_FORMAT_INSTRUCTIONS]
For OUT_OF_SCOPE responses: Use only the redirection template above.

Adaptation guidance: Replace all square-bracket placeholders with domain-specific values. The IN_SCOPE_TOPIC and OUT_OF_SCOPE_CATEGORY lists should be exhaustive enough to prevent boundary ambiguity but not so granular that the model struggles to classify edge cases. Test the template with the domain-boundary stress tests described in the evaluation section of this playbook. For regulated domains, add a [COMPLIANCE_REQUIREMENTS] section that references specific regulatory constraints the assistant must uphold. If your assistant uses tools, add a [TOOL_AUTHORIZATION_BOUNDARY] section that restricts tool calls to in-scope operations only.

The Scope Limitation Prompt is not a standalone artifact; it is a policy layer that must be integrated into your application's request pipeline. The prompt defines the rules, but your application code enforces them. The primary integration points are: (1) injecting the system prompt before every user turn, (2) parsing the model's output for boundary-violation signals, (3) routing off-topic requests to a safe fallback, and (4) logging every boundary decision for audit and monitoring. In a typical setup, the system prompt is prepended to the conversation context, and the user's message is appended as the latest turn. The model's response is then inspected for structured signals—such as a [DOMAIN_VIOLATION] token or a JSON field like "in_domain": false—before the response is returned to the user or passed to downstream tools.

For production-grade reliability, implement a validation layer that checks the model's output against expected boundary markers. If the model is instructed to wrap off-topic responses in a specific format (e.g., {"in_domain": false, "redirect_message": "..."}), use a JSON schema validator to confirm the structure. If validation fails, retry the prompt once with a stronger instruction: 'You must respond with valid JSON. If the query is outside the domain, set in_domain to false.' After two failures, escalate to a human reviewer or return a hardcoded safe-redirect message. Logging is critical: capture the user input, the model's raw output, the parsed boundary decision, and any retry attempts. This log becomes your audit trail for domain-boundary violations and helps tune the prompt over time. For high-stakes domains like healthcare or legal, route all boundary-violation cases to a review queue before any automated redirect is shown to the user.

Model choice matters. Smaller or older models may struggle to consistently produce structured boundary signals. If you are using a model without strong instruction-following, consider a two-pass architecture: first, a lightweight classification prompt that returns only in_domain or out_of_domain, and second, the full assistant prompt that only runs for in-domain queries. This reduces latency and cost for off-topic requests. Tool use should be gated behind the boundary check: if the query is out of domain, do not pass it to any domain-specific tools, APIs, or retrieval steps. Instead, return the redirect message immediately. For RAG-based assistants, the boundary check should run before retrieval to prevent off-topic queries from pulling sensitive or irrelevant documents. Finally, avoid the trap of relying solely on the prompt for enforcement—always implement an application-level circuit breaker that catches boundary violations the model misses, especially when the cost of overreach is high.