Risk Tier Assignment Prompt Template

This prompt is for safety platform builders, trust-and-safety engineers, and ML ops teams who need to translate organizational policy severity definitions into a consistent, machine-actionable risk tier for every request category. The job-to-be-done is not just classification; it is creating a repeatable, auditable mapping from a policy document and a request description to a structured risk label, an escalation path, and required approval gates. Use this when you are building or calibrating a safety enforcement pipeline and need every request type—from 'harmless chitchat' to 'regulated financial advice'—to land in the correct tier with clear downstream handling instructions.

This prompt is most effective when you have a defined, written safety policy with severity levels (e.g., 'Low: minor policy violation,' 'Critical: illegal or life-threatening content') and a taxonomy of request categories that need assignment. It expects you to provide the policy context, the request category, and a set of tier definitions. The output is not a free-text justification but a structured object containing the assigned tier, a confidence score, the escalation path, and a consistency check against similar categories. Do not use this prompt for real-time, per-message classification in a high-throughput chat system; it is a design-time or batch-calibration tool for building the routing rules that those real-time systems will later execute.

Avoid using this prompt when the policy itself is ambiguous, unwritten, or under active debate. The model cannot invent policy boundaries; it can only apply the definitions you provide. If you feed it vague severity descriptions, you will get inconsistent tier assignments that create compliance gaps. Before running this prompt, ensure your policy document has concrete, mutually exclusive tier definitions with examples. After running it, always conduct a human review of the assignments, especially for categories near tier boundaries, and run the companion Policy Enforcement Consistency Check prompt across your results to detect drift or bias.

This prompt template is designed for safety platform builders who need to classify request categories into consistent risk tiers. It takes a request category description and the relevant policy severity definitions as input, then produces a structured risk assignment with tier labels, escalation paths, required approval gates, and consistency checks against similar request types. The template uses square-bracket placeholders so you can swap in your own policy documents, request categories, and output schemas without rewriting the core instruction logic.

textCopy
You are a safety policy classification engine. Your task is to assign a risk tier to a given request category based on the provided policy severity definitions.

## INPUT
Request Category: [REQUEST_CATEGORY_NAME]
Category Description: [REQUEST_CATEGORY_DESCRIPTION]

## POLICY CONTEXT
Severity Definitions:
[POLICY_SEVERITY_DEFINITIONS]

Reference Classifications (similar categories already classified):
[REFERENCE_CLASSIFICATIONS]

## OUTPUT SCHEMA
Return a valid JSON object with these fields:
{
  "risk_tier": "low" | "medium" | "high" | "critical",
  "tier_label": "string (human-readable label matching policy taxonomy)",
  "confidence": 0.0-1.0,
  "rationale": "string (explain which severity criteria matched and why)",
  "escalation_path": "string (who reviews this tier: none, human_review, legal_review, executive_review)",
  "required_approval_gates": ["string (list of approval steps before response is allowed)"],
  "consistency_notes": "string (flag if this classification conflicts with any reference classification, and why)",
  "policy_citations": ["string (specific policy sections or clauses that apply)"]
}

## CONSTRAINTS
- If the category matches criteria for multiple tiers, assign the highest applicable tier.
- If the category is ambiguous or spans tier boundaries, set confidence below 0.8 and flag the ambiguity in rationale.
- Compare against reference classifications. If your assignment conflicts with a similar category, explain the conflict in consistency_notes.
- Do not invent policy rules. Cite only from the provided severity definitions.
- If the category description is insufficient to classify, return confidence 0.0 and request more detail in rationale.

## EXAMPLES
[EXAMPLES]

## TOOLS
[TOOLS]

To adapt this template for your environment, replace the square-bracket placeholders with your actual policy content. The [POLICY_SEVERITY_DEFINITIONS] placeholder should contain your organization's tier definitions with clear criteria for each level (for example, what makes something 'critical' versus 'high'). The [REFERENCE_CLASSIFICATIONS] field is essential for consistency—populate it with at least 5-10 previously classified categories so the model can calibrate its assignments. The [EXAMPLES] section should include 2-3 worked examples showing correct tier assignments with full rationale. If your system supports tool calls, use [TOOLS] to provide a function schema that enforces the output structure rather than relying on JSON parsing alone. Before deploying, run this prompt against a golden dataset of 20-50 known classifications and measure inter-rater agreement against human-labeled tiers. Any category where confidence falls below 0.8 or where consistency_notes flags a conflict should route to human review rather than being accepted automatically.

The Risk Tier Assignment prompt is not a standalone chatbot interaction. It belongs inside a safety platform pipeline that classifies request categories before they reach a downstream model or agent. The typical integration point is a pre-processing step: a new request category definition arrives from a policy update or a product change, and the platform must assign a risk tier, escalation path, and approval gate before that category can be used in enforcement logic. Wire this prompt as a synchronous API call with a strict timeout, because risk tier assignment is a gating decision that blocks downstream configuration if it fails or returns ambiguous results.

Build the harness around three layers: input assembly, output validation, and audit persistence. For input assembly, populate [POLICY_DOCUMENT] from your policy registry, [REQUEST_CATEGORY] from the category definition queue, and [RISK_TIER_DEFINITIONS] from your organization's severity taxonomy. If your taxonomy includes numeric severity scores, legal review requirements, or data sensitivity levels, include those in the definitions block. For output validation, enforce a strict schema check: the response must contain a risk_tier field matching one of your defined tiers, an escalation_path array with at least one entry, and a required_approval_gates array. Reject any response that invents tiers not in your taxonomy or omits the escalation path. If validation fails, retry once with the validation error message appended to the prompt as [PREVIOUS_ERROR]. After a second failure, route to a human review queue rather than guessing. For audit persistence, log the full prompt, the model response, the validator result, the assigned tier, and the operator who approved or overrode the decision. This log becomes your evidence trail when auditors ask why a particular category was classified as low-risk.

Model choice matters here. Use a model with strong instruction-following and structured output support, such as GPT-4o or Claude 3.5 Sonnet, because the prompt requires precise adherence to a defined taxonomy and consistent reasoning across similar categories. Avoid smaller or older models that are more likely to hallucinate tier names or skip the escalation path. If you run this prompt in batch mode across dozens of new categories, add a consistency check as a post-processing step: after all categories are assigned, run a second pass that compares tiers across semantically similar categories and flags any that diverge by more than one severity level. This catches the most common production failure mode—inconsistent tier assignment across related request types—before the tiers are committed to enforcement configuration. Finally, never allow the model's output to directly update production policy enforcement rules without human approval. The prompt's required_approval_gates field should map to actual approval workflows in your policy management system, not just advisory text.