Risk-Level Instruction Branching Prompt

This prompt is for compliance and safety engineers who need to dynamically inject escalating constraints, refusal boundaries, and human-review requirements into a system prompt based on a runtime risk score. The job-to-be-done is modifying a base system prompt so that the model's behavior automatically tightens as the assessed risk of a user request increases, without maintaining dozens of static prompt variants. The ideal user is an engineering lead or safety engineer integrating this into a production AI gateway or orchestration layer where every request already carries a risk classification.

Use this prompt when you have a pre-calculated risk score or level (e.g., LOW, MEDIUM, HIGH, CRITICAL) available at inference time and you need the model's guardrails to match that level. It is appropriate for regulated domains, user-generated content moderation, high-stakes decision support, and any product surface where the cost of an unconstrained response is high. You must provide the base system prompt, the risk level, and a defined policy map that specifies what constraints activate at each level. Do not use this prompt when you lack a reliable risk signal, when the risk taxonomy is undefined, or when the base prompt already contains all necessary guardrails and does not need runtime modification.

This prompt is not a replacement for input filtering, output moderation, or human review workflows. It is a prompt assembly step that changes what the model is instructed to do. For CRITICAL risk levels, the assembled prompt should still be paired with downstream human approval before any action is taken. Before deploying, validate that the assembled prompt does not accidentally weaken existing guardrails and that the model respects the injected refusal boundaries under test. The next section provides the copy-ready template you can adapt to your risk taxonomy and policy map.

The template below is the core assembly artifact for the Risk-Level Instruction Branching Prompt. It is designed to be populated at runtime by your application layer, not used as a static system message. The square-bracket placeholders represent variables that your prompt assembly logic must resolve before inference. The key variable is [RISK_LEVEL], which acts as the branching signal. Your application should map a risk score (e.g., from a classifier or business rules engine) to one of the predefined tiers—low, medium, high, or critical—and inject the corresponding instruction block. This ensures that the model's behavioral contract tightens precisely as the stakes increase, without requiring you to maintain four separate prompt templates.

codeCopy
You are a compliance-aware assistant operating in a regulated environment.
Your primary objective is to assist the user while adhering to the safety and compliance policy defined below.
The current operational risk level is [RISK_LEVEL].

<risk_policy>
[RISK_POLICY_BLOCK]
</risk_policy>

<user_request>
[USER_INPUT]
</user_request>

<output_requirements>
- Adhere strictly to the constraints defined in the <risk_policy> block for the current risk level.
- If the policy requires refusal, use the exact refusal language provided.
- If the policy requires human review, do not generate a final answer. Instead, output the [HUMAN_ESCALATION_FORMAT].
- If the policy permits a response, generate your output inside a <response> XML tag.
- Do not mention the risk level or the policy block in your output.
</output_requirements>

Adapting the Template The critical adaptation work happens in the [RISK_POLICY_BLOCK] variable. Your application must assemble this block by selecting the correct policy fragment for the current [RISK_LEVEL]. For example, a low risk level might inject a block that permits direct answers with standard disclaimers. A critical risk level would inject a block that mandates immediate refusal with a specific legal disclaimer and triggers a [HUMAN_ESCALATION_FORMAT] output. The [HUMAN_ESCALATION_FORMAT] placeholder should be replaced with a structured object your downstream system can parse, such as {"action": "ESCALATE", "reason": "Critical risk policy triggered.", "user_message": "This request requires review by a specialist."}. The [USER_INPUT] placeholder should be sanitized before insertion to prevent prompt injection that could attempt to override the risk policy.

Before deploying this template, validate your assembly logic with a preflight check. Ensure that for every possible [RISK_LEVEL] value, a non-empty [RISK_POLICY_BLOCK] is resolved. A missing policy block is a silent failure mode that defaults the model to its base behavior, effectively removing all safety guardrails. Log the resolved [RISK_LEVEL] and a hash of the [RISK_POLICY_BLOCK] as part of your inference trace to enable post-hoc audits. In high-risk and critical tiers, pair this prompt with a human-in-the-loop queue; the model's output should be treated as a draft escalation ticket, not an autonomous action.

The risk-level instruction branching prompt is not a standalone prompt—it is a prompt assembly function that takes a runtime risk score and returns a modified system prompt with risk-appropriate guardrails. In production, this function sits between your risk classifier and the model inference call. The application flow is: (1) classify the incoming request or context to produce a risk score and category, (2) call this branching prompt with the base system prompt and the risk classification as inputs, (3) validate the assembled prompt before sending it to the model, and (4) log the risk score, branch chosen, and assembled prompt for auditability.

Validation and preflight checks are critical here because a malformed assembled prompt can silently drop safety instructions. Before sending the assembled prompt to the model, run a preflight validator that checks: (a) the output contains a complete system prompt, not just a fragment, (b) refusal boundaries and escalation language are present when the risk score exceeds your defined threshold, (c) no placeholder tokens remain unresolved, and (d) the assembled prompt does not exceed your model's context window. If validation fails, fall back to a known-safe restrictive system prompt and log the failure for investigation. For high-risk domains such as healthcare or finance, the assembled prompt should be reviewed by a human before deployment to production traffic—treat the prompt assembly output as code that requires approval.

Model choice matters. The branching prompt itself can run on a smaller, faster model (such as GPT-4o-mini or Claude Haiku) because it is performing a structured assembly task, not generating user-facing output. The assembled system prompt is then used with your primary model for the actual inference. This keeps latency low and costs controlled. Retries should be limited: if the branching prompt fails to produce a valid assembled prompt after two attempts, fall back to the restrictive default and alert the on-call channel. Observability requires logging the risk score, the branch identifier, the full assembled prompt, and the validator result on every call. Use trace IDs to link the assembly step to the downstream inference call so you can diagnose whether a safety failure originated in the branching logic or in the model's response to the assembled prompt.

Eval checks must cover both under-blocking and over-refusal. Build a test suite of inputs at each risk level and verify that the assembled prompt includes the expected guardrail language for high-risk inputs and does not inject unnecessary restrictions for low-risk inputs. Run these evals on every prompt template change and on every model version upgrade for the model that runs the branching prompt. What to avoid: do not use the branching prompt to make real-time safety decisions without the preflight validator; do not skip logging the assembled prompt, because without it you cannot debug production incidents; and do not assume the branching prompt will always produce a valid output—always have a restrictive fallback system prompt ready and tested.