Out-of-Scope Detection Prompt for Boundary Enforcement

This prompt is designed for safety engineers and product teams who need a deterministic, auditable gate that enforces the declared capability boundaries of an AI system. Its job is to receive a user input and a machine-readable policy document, then return a structured decision: in_scope or out_of_scope. For out-of-scope requests, it also produces a stable reason code and a safe, graceful rejection message that can be surfaced directly to the user or logged for review. Use this prompt when you need a single, consistent enforcement point before any model reasoning, tool use, or data access occurs—particularly in customer-facing products where hallucinating an answer to an unsupported request damages trust or creates liability.

Deploy this prompt at the ingress layer of your AI pipeline, immediately after input sanitization and before intent classification or agent dispatch. It works best when your system has a clearly defined, version-controlled capability boundary document that enumerates supported domains, excluded categories, and edge-case handling rules. The prompt expects that boundary policy as a structured input alongside the user message, which means you can update your system's scope without changing the prompt itself—just update the policy payload. Do not use this prompt for ambiguous gray-area detection where you need nuanced confidence scores; it is optimized for binary enforcement with clear rejection paths. For ambiguous cases, pair it with an upstream ambiguity detection prompt that can request clarification before reaching this gate.

Avoid deploying this prompt as the sole safety mechanism in high-stakes regulated domains without a human review fallback for edge cases. The prompt is strong at enforcing explicit boundaries but can be brittle when policy documents contain contradictions or when users employ sophisticated social engineering to reframe out-of-scope requests. Always log the reason codes and rejection messages for false-positive analysis, and set up a monitoring dashboard that tracks rejection rates by category. If your rejection rate spikes in a particular category, investigate whether your boundary policy is too restrictive or whether users have a legitimate unmet need that should be added to scope. The next section provides the copy-ready prompt template you can adapt to your own boundary policy format.

This template provides the core instruction set for an out-of-scope detection prompt. It is designed to be injected into a system prompt or used as a standalone classifier. The prompt forces the model to make a binary decision, provide a structured reason code, and generate a graceful, non-hallucinatory rejection message when a request falls outside the system's defined boundaries. This is not a generic safety filter; it is a capability boundary enforcer that prevents the system from attempting tasks it was not designed to handle.

codeCopy
You are a boundary enforcement classifier. Your only job is to determine if a user request falls within the system's defined capabilities.

## SYSTEM CAPABILITIES
[CAPABILITY_DEFINITION]

## USER REQUEST
[USER_INPUT]

## INSTRUCTIONS
1. Analyze the user request against the system capabilities above.
2. If the request is fully addressable by the capabilities, classify as "in_scope".
3. If any part of the request requires capabilities not listed, classify as "out_of_scope".
4. For out-of-scope requests, identify the primary reason from the [REASON_CODE_LIST].
5. Generate a rejection message that is polite, helpful, and does not hallucinate capabilities.

## OUTPUT SCHEMA
Respond with a single JSON object:
{
  "classification": "in_scope" | "out_of_scope",
  "reason_code": "[REASON_CODE_LIST]",
  "rejection_message": "string, only if out_of_scope, otherwise null",
  "violated_capability": "string, the specific capability that is missing, only if out_of_scope"
}

## CONSTRAINTS
- Do not attempt to fulfill the user request.
- Do not provide partial solutions for out-of-scope requests.
- The rejection message must not imply future capability.

To adapt this template, replace [CAPABILITY_DEFINITION] with a clear, bulleted list of what your system can actually do. The [REASON_CODE_LIST] should be a finite set of codes like unsupported_domain, requires_external_action, prohibited_use_case, or missing_tool. The [USER_INPUT] placeholder receives the raw user message. For high-stakes domains, always route out_of_scope classifications to a human review queue before sending the rejection message to the user, and log the reason_code and violated_capability for boundary policy review.

The out-of-scope detection prompt is a pre-processing guard that should execute before any domain-specific logic, tool dispatch, or LLM generation. In a typical request pipeline, this prompt sits immediately after input ingestion and PII redaction, but before intent classification or model routing. Its job is to produce a binary in_scope / out_of_scope decision with a machine-readable reason_code and a user-facing rejection_message. The rejection message must be safe to display directly to end users without modification—never include internal system details, policy names, or capability hints that could be exploited in adversarial probing.

Integration pattern: Call this prompt synchronously and block downstream processing when in_scope is false. The recommended flow: (1) Receive user input. (2) Run PII redaction if needed. (3) Execute the out-of-scope detection prompt with the current [BOUNDARY_POLICY] injected from a configuration store. (4) Parse the JSON response and validate the schema—reject malformed outputs as a system error. (5) If in_scope is false, return the rejection_message to the user with HTTP 422 or an equivalent "unprocessable" status, log the reason_code and input hash, and increment a rejection_count metric. (6) If in_scope is true, pass the input to the next stage (intent classification, tool router, or agent loop). Never fall through to generation on a parse failure—treat unparseable outputs as out-of-scope with a generic fallback message.

Validation and retries: The output must conform to a strict schema: {"in_scope": boolean, "reason_code": string, "rejection_message": string | null}. Validate this with a JSON schema validator in application code, not with a follow-up LLM call. If validation fails, retry once with the same prompt and a stronger constraint instruction appended (e.g., "You must respond with valid JSON only"). If the retry also fails, log the raw output, return the generic rejection message, and fire an alert for prompt degradation. Do not retry more than once—latency budgets for guard prompts should be tight (under 500ms p95).

Observability and policy updates: Log every decision with reason_code, input_hash, model_version, prompt_version, and latency_ms. Build a dashboard that tracks rejection rates by reason code and monitors for sudden spikes that indicate policy drift or adversarial campaigns. The [BOUNDARY_POLICY] placeholder should be populated from a version-controlled configuration file or feature flag, not hardcoded. When the product scope expands, update the policy document, run the new prompt version against a golden dataset of known in-scope and out-of-scope examples, and compare rejection rates before promoting. Human review is required when the rejection rate shifts by more than 5% in a release window or when a new reason_code appears in production traffic—this may indicate misclassification or an unanticipated user need that should be routed to product management, not silently rejected.