Risk Boundary Assessment Prompt for User Inputs

This prompt is a pre-processing gate for security and compliance engineers who need to evaluate user inputs against a configurable risk taxonomy before any model invocation, tool execution, or data access occurs. The core job-to-be-done is producing an explainable, auditable risk verdict that a downstream application can act on deterministically. You should use this prompt when you need a structured JSON output containing a risk score, a list of matched boundary categories with supporting evidence, and a clear routing decision (allow, review, block). The ideal user is an AI platform engineer integrating this into a request pipeline where every input must be assessed for policy, safety, or domain risk before it reaches more expensive or sensitive systems.

This is not a general-purpose safety classifier or a real-time content moderation filter. Do not use this prompt when your latency budget is under 50ms; a dedicated, fine-tuned classifier model is more appropriate for high-throughput, low-latency moderation. It is also not a replacement for a full policy engine. The prompt's strength is in providing natural-language explanations and evidence for its decisions, making it suitable for workflows that require an audit trail. You must provide a specific, well-defined risk taxonomy as part of the [CONTEXT] or [CONSTRAINTS]. Without a clear taxonomy, the model's boundary decisions will be inconsistent and un-auditable. The prompt is designed to be a single step in a larger harness, not a standalone product.

Before implementing, confirm that your use case requires explainability and structured evidence for each risk decision. If you only need a binary block/allow signal, a simpler classification model will be faster and cheaper. If you adopt this prompt, pair it with a validation layer that checks the output schema, a logging system that records the full prompt and verdict for auditability, and a human review queue for all inputs flagged as review. The next section provides the copy-ready prompt template you will adapt to your specific risk taxonomy.

This prompt template is designed to be the core instruction set for a risk boundary classifier. It accepts a user input and a defined risk taxonomy, then produces a structured JSON output containing a risk score, matched boundary categories, and a routing decision. The template uses square-bracket placeholders for all dynamic components, making it straightforward to integrate into a prompt assembly pipeline where the application layer injects the current taxonomy, input, and output schema before each inference call.

textCopy
You are a risk boundary classifier. Your task is to evaluate the following user input against a provided risk taxonomy and determine whether it should be allowed, reviewed, or blocked.

## RISK TAXONOMY
[RISK_TAXONOMY]

## USER INPUT
[USER_INPUT]

## INSTRUCTIONS
1. Analyze the user input for any content that matches categories in the risk taxonomy.
2. For each matched category, cite the specific phrase or pattern from the input that triggered the match.
3. Assign an overall risk score from 0.0 (no risk) to 1.0 (maximum risk).
4. Determine a routing decision: "allow", "review", or "block".
   - "allow": No risk categories matched, or only categories with a severity of "low" were matched.
   - "review": One or more "medium" severity categories matched, but no "high" or "critical" categories.
   - "block": Any "high" or "critical" severity category matched.
5. If the decision is "review" or "block", provide a concise, non-alarming explanation suitable for an audit log.

## OUTPUT SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "risk_score": <float between 0.0 and 1.0>,
  "matched_categories": [
    {
      "category": "<string>",
      "severity": "<low|medium|high|critical>",
      "trigger": "<exact phrase or pattern from input>"
    }
  ],
  "routing_decision": "<allow|review|block>",
  "explanation": "<string, required if decision is review or block, otherwise null>"
}

## CONSTRAINTS
- Do not hallucinate risk categories that are not in the provided taxonomy.
- If no categories match, return an empty list for "matched_categories" and a risk_score of 0.0.
- Base your decision strictly on the provided taxonomy and input. Do not apply external knowledge of risk.

To adapt this template, replace [RISK_TAXONOMY] with your organization's specific risk categories, each having a name and a severity level (low, medium, high, critical). The taxonomy can be injected as a structured markdown list or a JSON object, depending on what your model parses most reliably. The [USER_INPUT] placeholder should receive the raw, unmodified text from the end user. Before deploying, test the prompt with a golden dataset of inputs that span all severity levels, including edge cases that sit exactly on the boundary between "review" and "block." Monitor the risk_score distribution in production to detect taxonomy drift or adversarial inputs designed to score just below the blocking threshold.

The Risk Boundary Assessment prompt is designed to sit at the ingress point of your AI pipeline, before any model invocation or tool execution. It should be called synchronously for real-time user inputs or as a pre-processing step in batch pipelines. The prompt expects a user input string and a configurable risk taxonomy, and it returns a structured JSON object containing a risk score, matched boundary categories, and a routing decision (allow, review, block). The routing decision must be enforced by application code, not by trusting the model's output alone. For high-risk domains, always require human review for any input classified as 'review' or 'block' before allowing further processing.

To integrate this prompt, wrap it in a thin service that handles input sanitization, model invocation, and output validation. First, validate the model's JSON response against a strict schema: the risk_score must be a float between 0.0 and 1.0, matched_categories must be an array of strings drawn from your predefined taxonomy, and routing_decision must be one of the enum values allow, review, or block. If validation fails, retry the prompt once with the validation error message appended to the context. If the retry also fails, default to block and log the failure for investigation. Log every assessment result—including the input hash, risk score, matched categories, routing decision, model version, and timestamp—to an append-only audit store. This audit trail is critical for compliance reviews and for tuning the risk taxonomy over time.

For model choice, use a fast, cost-efficient model for this classification task. A smaller model like GPT-4o-mini, Claude Haiku, or a fine-tuned open-weight model is sufficient for boundary assessment and keeps latency low. Avoid using large, expensive models for this pre-processing step unless your risk taxonomy requires nuanced reasoning that smaller models consistently fail. Implement a latency budget: if the assessment takes longer than 500ms, consider caching results for identical inputs or falling back to a simpler keyword-based filter. For high-throughput systems, batch assessments where possible, but be aware that batching may delay the routing decision and is unsuitable for real-time chat applications.

The most common failure mode is over-classification, where the model flags benign inputs as risky. Monitor the ratio of review and block decisions to total assessments, and set alerts if the block rate spikes unexpectedly. Regularly sample review decisions to check for false positives, and use those samples to refine your risk taxonomy or adjust the prompt's instructions. Another failure mode is taxonomy drift: as your product evolves, new risk categories may emerge that the prompt doesn't cover. Schedule quarterly reviews of the risk taxonomy and update the prompt's category definitions accordingly. Never allow the model to invent new risk categories on the fly—always constrain matched_categories to your predefined taxonomy.

When a block or review decision is returned, the application must not proceed with the user's request. For block decisions, return a generic refusal message to the user without revealing the specific risk category, which could be exploited by adversaries. For review decisions, queue the input for human review and inform the user that their request is being processed. The human reviewer should see the original input, the model's risk assessment, and any relevant context, and they should have the ability to override the decision. Log the reviewer's decision and use it to improve the prompt's accuracy over time through few-shot example updates or fine-tuning.