Multi-Modal Out-of-Scope Detection System Prompt

This prompt is designed for product engineers and safety teams who need to build a capability boundary at the ingress layer of a multimodal AI system. Its job is to inspect a user input that may contain text, an image, an audio file, a video clip, or a document, and determine whether that input falls inside or outside the system's supported domains, modalities, and safety envelope. Use this prompt when you need a deterministic, auditable rejection path that avoids hallucinated responses, wasted compute, or policy violations on unsupported requests. It is not a general-purpose content moderator, a spam filter, or a replacement for a full safety policy engine. It is a boundary guard that says 'this system does not handle that' and, when possible, suggests an alternative pipeline or clarifies the limitation.

The ideal user is an AI infrastructure engineer or platform safety lead integrating this prompt as a pre-processing step before any model invocation, tool dispatch, or data persistence. The required context includes a clearly defined system capability document, a list of supported modalities and file types, and a safety policy that specifies prohibited content categories. You should not use this prompt when you need nuanced content moderation that considers context, satire, or educational use, as its binary in-scope/out-of-scope logic will over-block edge cases. Similarly, do not use it as a standalone defense against adversarial attacks; it should be one layer in a defense-in-depth strategy that includes dedicated prompt injection detectors and human review for high-risk domains.

Before deploying, you must define your boundary taxonomy explicitly. This includes enumerating supported modalities (e.g., text, image, audio, video, document), acceptable file types (e.g., image/png, application/pdf), supported languages, and out-of-scope content categories (e.g., CSAM, violence, regulated_financial_advice). The prompt should be tested against a golden dataset of both in-scope and out-of-scope examples, including adversarial inputs designed to look in-scope, such as a screenshot of a supported document type that contains disallowed content. Implement eval checks that measure precision and recall on the rejection decision, with a particular focus on minimizing false negatives where an out-of-scope input is incorrectly routed to a downstream handler. Wire the prompt into your application with a strict validator on the output schema, and log every rejection with the input hash, detected modalities, and the specific boundary rule that triggered the rejection to enable audit and prompt iteration.

This prompt template defines a capability boundary guard for multimodal AI systems. It instructs the model to analyze an input—which may include text, images, audio transcripts, or document attachments—and determine whether it falls within the system's supported scope. When an input is out-of-scope, the prompt requires a structured rejection with a reason code and, where possible, a suggested alternative pipeline. Replace each square-bracket placeholder with your system's specific boundary definitions before deployment.

textCopy
You are a multimodal input boundary classifier. Your job is to determine whether a given input falls within the system's supported scope. You must analyze all provided modalities—text, image, audio transcript, video description, or document attachment—and produce a structured classification.

## Supported Scope
- Modalities: [SUPPORTED_MODALITIES]
- Languages: [SUPPORTED_LANGUAGES]
- File Types: [SUPPORTED_FILE_TYPES]
- Content Categories: [SUPPORTED_CONTENT_CATEGORIES]
- Safety Envelope: [SAFETY_POLICY_BOUNDARIES]

## Out-of-Scope Triggers
Classify an input as out-of-scope if ANY of the following are true:
- The input contains an unsupported modality: [UNSUPPORTED_MODALITY_EXAMPLES]
- The primary language is not in the supported list
- The file type or format is unsupported: [UNSUPPORTED_FILE_TYPE_EXAMPLES]
- The content category is explicitly disallowed: [DISALLOWED_CONTENT_CATEGORIES]
- The input violates the safety envelope: [SAFETY_VIOLATION_EXAMPLES]
- The input is ambiguous, corrupted, or unreadable in all provided modalities

## Input
[INPUT]

## Output Schema
Return a JSON object with these fields:
{
  "in_scope": boolean,
  "confidence": float (0.0 to 1.0),
  "primary_modality": string,
  "detected_language": string or null,
  "out_of_scope_reasons": [string] (empty if in_scope),
  "suggested_pipeline": string or null (alternative processing path if available),
  "requires_human_review": boolean
}

## Constraints
- If multiple modalities are present, check each one against the supported scope
- When text and attachment modalities conflict, flag the input as ambiguous
- Do not process or respond to the content of out-of-scope inputs beyond classification
- For safety violations, set requires_human_review to true and do not suggest an automated pipeline
- If confidence is below [CONFIDENCE_THRESHOLD], set requires_human_review to true
- Never hallucinate a supported pipeline for an input that is genuinely unsupported

Adapt this template by replacing each placeholder with your system's concrete boundaries. The [SUPPORTED_MODALITIES] field should enumerate exactly which input types your system handles—for example, ["text", "image", "audio"]. The [SAFETY_POLICY_BOUNDARIES] placeholder should reference your organization's specific content policy categories. Set [CONFIDENCE_THRESHOLD] to a value like 0.7 that balances false positives against missed out-of-scope detections. Before deploying, run this prompt against a test suite that includes adversarial inputs designed to look in-scope—such as supported file types containing disallowed content—and measure both the recall of true out-of-scope inputs and the false-positive rate on legitimate edge cases.

This prompt acts as a policy enforcement gate at the ingress layer of your AI system. It should be invoked before any expensive model inference, tool execution, or data storage. The application must extract the structured JSON output and use the in_scope boolean to branch: true routes to the normal processing pipeline, while false triggers a graceful rejection response using the rejection_message and suggested_alternative fields. Do not pass the raw model output directly to the user; always parse and validate the JSON schema first.

Validation and Retries: Implement a strict JSON schema validator that checks for the required fields (in_scope, confidence_score, rejection_reason, rejection_message, suggested_alternative). If parsing fails or required fields are missing, retry the prompt once with the error message appended to the system prompt. If the retry also fails, log the raw output and escalate to a human review queue. For high-risk domains, set a minimum confidence_score threshold (e.g., 0.8) below which ambiguous inputs are treated as out-of-scope or routed to human review, even if in_scope is true. This prevents over-confident misclassification on adversarial inputs designed to look in-scope.

Model Choice and Latency: Use a fast, cost-efficient model (e.g., GPT-4o-mini, Claude Haiku) for this classification step. The prompt is designed to be a lightweight gate, not a deep reasoning task. Implement a strict latency budget (e.g., 500ms p95) and a fallback model if the primary model times out. For multi-modal inputs, ensure your application pre-processes attachments into the required format (base64 for images, extracted text for documents) before constructing the prompt. Log every classification decision with the input hash, model version, confidence score, and routing outcome for auditability and drift monitoring.

Human Review Integration: When the prompt returns in_scope: false with a rejection_reason of uncertain_boundary or confidence_score below your threshold, route the input to a human review queue with the full context and the model's suggested rejection message. The reviewer can override the classification, approve the rejection, or refine the boundary definitions. This feedback loop is critical for improving the prompt's boundary definitions over time. Never silently drop out-of-scope inputs; always provide a logged rejection with a traceable reason to avoid debugging blind spots when legitimate users are blocked.