Regulated Domain Request Triage Prompt

This prompt is a production guardrail for compliance engineers and platform operators who need a deterministic, auditable decision before a general-purpose model responds to a user. Its job is to classify whether a user request crosses into a regulated domain—specifically medical, legal, or financial advice—and to produce a structured triage decision that routes the request to either an automated safe-alternative flow or a human professional review queue. Use it when the cost of an unqualified AI response includes real legal liability, professional licensing violations, or regulatory penalty, not just brand risk. It is not a classifier for generic safety policy violations like hate speech or self-harm; those belong to a separate unsafe-request detection workflow.

The ideal operator is a compliance or trust-and-safety engineer integrating this prompt into an AI gateway, a model router, or a post-hoc audit pipeline. You need a defined regulated-domain policy that specifies what constitutes medical, legal, or financial advice in your jurisdiction and product context. The prompt requires a user request as input and expects a structured JSON output containing a binary classification, a risk level, a domain boundary analysis, and a routing instruction. Do not use this prompt if you lack a human review queue to receive escalations; routing to a dead letter queue creates a worse compliance posture than a well-engineered refusal. Do not use it to generate the actual regulated advice—even for testing—because the model may produce convincing but non-compliant content.

Before deploying, define your escalation path and test the prompt against a golden dataset of borderline requests that sit near your policy boundaries. Common failure modes include over-classifying benign informational questions as regulated advice and under-classifying indirect requests that imply a need for professional judgment. Wire the output into a decision harness that logs every triage result, measures the false-positive escalation rate against your review team's capacity, and feeds ambiguous cases back into policy clarification. The next step after reading this section is to review the prompt template and adapt its domain boundary definitions to your specific regulatory context.

This prompt template is designed to be pasted directly into your system prompt, safety classifier, or an initial triage step in your AI application. It forces the model to act as a strict boundary classifier, not a subject-matter expert. The core job is to analyze the user's request against a defined set of regulated domain criteria and output a structured routing decision. The template uses square-bracket placeholders for all dynamic inputs, allowing you to adapt it to your specific compliance policies, risk tolerance, and review queue structure without rewriting the core logic.

textCopy
You are a compliance triage classifier. Your only job is to analyze the following user request and determine if it crosses into a regulated domain that requires mandatory human professional review. Do not answer the user's request. Do not provide advice, information, or alternatives. Only classify and route.

## Regulated Domain Definitions
[DEFINITIONS]

## User Request
[INPUT]

## Classification Rules
1. If the request explicitly asks for professional advice, diagnosis, legal interpretation, or financial recommendations within a regulated domain, classify as `ROUTE_TO_HUMAN`.
2. If the request provides specific personal context (symptoms, legal situation, financial details) and asks for analysis or a course of action, classify as `ROUTE_TO_HUMAN`.
3. If the request asks for general educational information about a regulated topic without personal context or a request for application, classify as `SAFE_TO_RESPOND`.
4. If the request is ambiguous, default to `ROUTE_TO_HUMAN` with a `LOW_CONFIDENCE` flag.

## Output Schema
Return ONLY a valid JSON object with no other text:
{
  "classification": "ROUTE_TO_HUMAN" | "SAFE_TO_RESPOND",
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "regulated_domain": ["DOMAIN_NAME"] | [],
  "reasoning": "Brief, specific explanation citing the part of the request that triggered this classification.",
  "recommended_queue": ["QUEUE_NAME"] | []
}

## Constraints
- Do not generate any text outside the JSON object.
- If classification is `SAFE_TO_RESPOND`, `recommended_queue` must be an empty array.
- If confidence is `LOW`, classification must be `ROUTE_TO_HUMAN`.

To adapt this template for your production environment, start by populating the [DEFINITIONS] placeholder with precise, policy-aligned descriptions of each regulated domain you need to enforce. For example, define 'Medical Advice' as 'Requests that ask for diagnosis, treatment recommendations, or interpretation of symptoms for a specific individual.' Vague definitions cause inconsistent classification. Next, map the [QUEUE_NAME] values to actual routing targets in your system, such as 'legal_review_queue' or 'clinical_escalation_queue'. The output schema is designed for direct parsing by an application harness, so maintain the exact field names and enum values. Before deploying, run this prompt against a golden dataset of known safe and regulated requests to calibrate your confidence thresholds and ensure the LOW_CONFIDENCE default-to-escalate behavior is not generating an unmanageable review queue volume.

This prompt is designed to sit at the boundary between user input and your core application logic. It should be invoked before any substantive model response is generated, acting as a synchronous classification gate. The ideal integration point is within an API middleware layer or a serverless function that intercepts every user message. The prompt's output is a structured JSON classification object, which your application must parse to decide the next step: allow the request to proceed to the main conversational or task model, block it with a safe refusal, or route it to a human review queue. Do not stream the triage prompt's output to the user; it is a control-plane decision, not a user-facing message.

Wiring the prompt into your application requires a strict contract. The prompt expects a [USER_QUERY] and a [DOMAIN_DEFINITIONS] object that maps regulated domains (e.g., medical, legal, financial) to boolean flags and jurisdictional notes. Your application must inject these at runtime. After the model responds, validate the output against a JSON schema that enforces the presence of classification, regulated_domain, confidence_score, and rationale fields. If validation fails, retry once with a repair prompt that includes the schema and the malformed output. If the retry also fails, default to the safest action: route to human review and log the failure as a critical error. For model choice, a fast, cost-effective model like GPT-4o-mini or Claude Haiku is sufficient for classification; reserve larger models for the downstream task that the triage prompt is protecting.

Routing logic must be implemented in application code, not in the prompt. Use the classification field to drive a switch statement: allowed requests proceed; refused requests trigger a safe-refusal response (potentially using a separate Refusal Style prompt); escalate requests are pushed to a review queue with the full triage output and session context attached. For escalate decisions, include a routing_target field in your application's internal payload—mapped from the prompt's regulated_domain output—to send the item to the correct legal, medical, or compliance review team. Log every triage decision, including the raw user input, the prompt version, the model response, and the routing outcome, to create an audit trail for compliance and prompt evaluation. Never log PII in plaintext unless required and secured.

Testing and evaluation must cover both safety and throughput. Build a golden dataset of 200+ queries spanning clear non-regulated requests, clear regulated requests, and ambiguous boundary cases. Measure precision and recall for each classification label, with a specific focus on false negatives (regulated requests misclassified as allowed). Set a minimum recall target of 0.99 for the regulated and escalate classes; a single miss here is a compliance incident. Also measure latency at the 95th percentile (p95) to ensure the triage step doesn't degrade user experience. If p95 latency exceeds 500ms, consider model distillation or caching common non-regulated query patterns. Run this evaluation suite as a gate in your CI/CD pipeline before any prompt or model change reaches production. The next step is to integrate the triage output with your downstream refusal and handoff prompts to create a complete safety flow.