Contextual Safety Judgment Prompt Template

This prompt is for trust and safety engineers, policy ops teams, and AI platform builders who need a single evaluator that applies different safety policies depending on who the user is, where they are, or what context they operate in. Use it when a one-size-fits-all safety classifier produces too many false refusals for legitimate enterprise, educational, or regulated use cases. The prompt acts as an LLM judge that reads the user request, the applicable policy tier, and any contextual modifiers, then returns a structured ruling with a clear rationale.

The ideal deployment is an offline evaluation pipeline, a policy testing harness, or an asynchronous human-review queue. In these settings, the prompt receives a batch of user requests, each tagged with a policy tier (e.g., enterprise-admin, k12-student, eu-regulated) and optional context modifiers (e.g., jurisdiction=DE, data_classification=internal). The output is a structured JSON ruling that includes a decision (allow, refuse, escalate), the specific policy clause referenced, a confidence score, and a human-readable rationale. This structure lets you run automated evals comparing the judge's decisions against a golden dataset of expected outcomes per tier, and it gives human reviewers enough detail to override decisions quickly.

Do not use this prompt for real-time blocking with latency under 200ms; it is designed for depth over speed. If you need inline safety checks inside a chat completion loop, use a smaller, fine-tuned classifier or a fast rule-based filter, and reserve this prompt for auditing that classifier's decisions. Also avoid this prompt when the policy tier is static and well-defined for all users—in that case, a single-tier refusal prompt with fewer tokens will be cheaper and easier to calibrate. Finally, this prompt is not a replacement for legal review of your safety policies; it operationalizes policies you have already defined, but it cannot invent jurisdictionally correct rules from scratch.

This template produces a structured safety ruling that accounts for user role, context, and jurisdiction rather than applying a single blanket policy. Replace each square-bracket placeholder with live data before every call. The prompt is designed to be wired into an automated evaluation harness where outputs are validated against expected rulings, but it also works for manual spot-checking during policy development.

textCopy
You are a context-aware safety classifier. Your task is to evaluate whether a given user request should be allowed, refused, or escalated based on the applicable policy tier, user context, and jurisdictional constraints.

## INPUT
User Request: [USER_REQUEST]
User Role: [USER_ROLE]
User Context: [USER_CONTEXT]
Jurisdiction: [JURISDICTION]
Conversation History (last 3 turns): [CONVERSATION_HISTORY]

## POLICY TIERS
Review the request against the policy tier that applies to this user role and jurisdiction. If multiple tiers could apply, use the most restrictive one.

[POLICY_TIERS]

## OUTPUT SCHEMA
Return a valid JSON object with exactly these fields:
{
  "decision": "allow" | "refuse" | "escalate" | "clarify",
  "policy_tier_applied": string,
  "policy_clause_cited": string,
  "rationale": string,
  "risk_score": number (0.0 to 1.0),
  "safe_alternative": string | null,
  "escalation_reason": string | null,
  "clarifying_question": string | null,
  "context_factors_considered": [string]
}

## CONSTRAINTS
- If the request is unambiguously allowed under the applicable tier, return "allow" with risk_score below 0.3.
- If the request is unambiguously disallowed, return "refuse" with the specific policy clause cited.
- If the request falls in a gray zone where context or role changes the ruling, return "clarify" and provide a specific clarifying question.
- If the request requires human review due to severity, ambiguity, or jurisdictional conflict, return "escalate" with a clear escalation reason.
- When refusing, always provide a constructive safe_alternative if one exists. Set to null only if no safe alternative is possible.
- Consider the user's role and context explicitly in your rationale. Do not apply a one-size-fits-all policy.
- If conversation history shows prior clarifications or refusals, factor those into your decision.
- Do not invent policy clauses. Cite only clauses present in the provided POLICY_TIERS.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## OUTPUT
Return only the JSON object. No markdown fences, no commentary.

Adaptation notes: The [POLICY_TIERS] placeholder should contain your actual policy definitions with clear tier boundaries, example clauses, and role-to-tier mappings. The [FEW_SHOT_EXAMPLES] placeholder should include 3-6 labeled examples covering allow, refuse, escalate, and clarify decisions with context variations. For high-stakes domains, add a [HUMAN_REVIEW_THRESHOLD] constraint that forces escalation when risk_score exceeds a defined cutoff. Validate every output against the JSON schema before accepting it—malformed JSON in a safety pipeline is itself a failure mode.

The Contextual Safety Judgment prompt is not a one-shot classifier; it is a structured ruling engine that must be integrated into a broader safety evaluation pipeline. The harness should treat each invocation as producing a decision record that can be audited, compared against human labels, and rolled back if the policy tier or context model changes. Wire this prompt as a dedicated step after content generation or user input ingestion, passing the full [USER_REQUEST], [CONTEXT] (role, jurisdiction, use case), and the applicable [POLICY_TIER] as inputs. The output—a ruling with rationale, policy reference, and context-appropriate determination—should be logged immutably alongside the model version, prompt version, and any override flags.

Build the harness with validation, retry, and escalation layers. First, validate the output schema: the ruling must contain a decision field (allow, refuse, escalate), a policy_tier_applied field matching one of the known tiers, and a rationale string that references specific policy clauses. If schema validation fails, retry once with a repair prompt that includes the validation error. If the retry also fails, escalate to a human review queue with the original inputs and both failed attempts. For high-stakes domains (healthcare, legal, crisis), always route escalate decisions to human review before any automated action. Use a model with strong instruction-following and low refusal hallucination—GPT-4o or Claude 3.5 Sonnet are reasonable defaults—and pin the model version in your harness config to prevent drift.

Evaluation is mandatory. Run every ruling through an automated judge that checks three properties: (1) context-appropriateness—does the decision match the expected behavior for the given role and jurisdiction? (2) policy grounding—does the rationale cite the correct policy tier and clause? (3) refusal correctness—no false refusals for legitimate use cases, no false allowances for prohibited ones. Maintain a golden dataset of context-prompt pairs with expected rulings, and run regression tests whenever the prompt template, policy tiers, or context model changes. Log every ruling with a unique judgment_id so downstream systems can trace decisions back to this prompt invocation. Avoid wiring this prompt directly into user-facing refusal messages; instead, use its structured output to drive a separate response-generation step that can apply tone and style controls appropriate to the user's context.