Review Item Guardrail Violation Evidence Packaging Prompt

This prompt is designed for trust and safety engineers and compliance officers who need to convert a raw guardrail violation signal into a structured, evidence-rich packet for a human reviewer. Use it when an automated system detects that an AI model's behavior has crossed a defined safety, policy, or operational boundary. The prompt's job is to gather the scattered context of the violation, reference the specific guardrail that was breached, classify the severity, and present a coherent case file. This is a critical step in a human-in-the-loop adjudication workflow, ensuring reviewers have everything they need to make a fast, accurate decision without hunting for context.

The ideal user is implementing a post-detection review queue, not a real-time blocking system. You should have the raw violation signal, the full conversation or action log, and the specific guardrail policy text available as inputs. The prompt expects these inputs to be assembled into a structured context block. It does not make the violation decision itself; it packages the evidence for a human who will make the final call. The output is a structured JSON packet containing a severity classification, a guardrail reference, a chronological evidence log, and a reviewer-ready summary.

Do not use this prompt for real-time blocking decisions or for automated enforcement actions. It is strictly for post-detection packaging. If your system requires immediate termination of a session or blocking of an output, handle that in the application layer before this prompt runs. Also, do not use this prompt when the violation signal is ambiguous or unclassified; it assumes a detection has already occurred. For ambiguous cases, route to an intent clarification or edge-case detection workflow first. Finally, ensure that the human review queue this packet feeds into is monitored and has defined SLAs; a well-packaged case file is useless if no one reviews it in time.

This prompt template is designed to be pasted into your system prompt or as a user message template in your AI harness. It instructs the model to take a raw guardrail violation event and produce a structured evidence packet that a human reviewer can quickly assess. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can wire it directly into your application's prompt assembly logic. The goal is to produce a consistent, evidence-backed packet that includes the violated guardrail, the specific context of the violation, and a preliminary severity classification.

textCopy
You are a Trust & Safety Evidence Packaging Assistant. Your task is to analyze a guardrail violation event and produce a structured evidence packet for a human adjudicator. Do not make a final decision; your role is to prepare the evidence clearly and completely.

### INPUTS
[VIOLATION_EVENT_DETAILS]
[GUARDRAIL_POLICY_DOCUMENT]
[RELEVANT_USER_INTERACTION_LOG]

### INSTRUCTIONS
1.  **Identify the Violated Guardrail:** Extract the exact clause or rule from [GUARDRAIL_POLICY_DOCUMENT] that was triggered. Quote it verbatim.
2.  **Package the Violation Context:** From [RELEVANT_USER_INTERACTION_LOG], isolate the specific turns, actions, or generated content that constitute the violation. Present this evidence with precise timestamps or sequence IDs.
3.  **Classify Severity:** Assign a preliminary severity level (`LOW`, `MEDIUM`, `HIGH`, `CRITICAL`) based on the definitions in [SEVERITY_CLASSIFICATION_RUBRIC]. Provide a concise, evidence-based justification for your classification.
4.  **Note Any Missing Information:** If critical evidence is missing from the provided logs to make a confident severity assessment, explicitly state what is missing in a `missing_evidence_notes` field.

### CONSTRAINTS
- Do not fabricate or infer details not present in the provided inputs.
- If the evidence is contradictory, flag the contradiction for the reviewer instead of trying to resolve it.
- Adhere strictly to the output schema defined in [OUTPUT_SCHEMA].
- If [RISK_LEVEL] is `HIGH` or `CRITICAL`, prepend the output with an `ESCALATION_NOTICE: HIGH PRIORITY REVIEW REQUIRED`.

### OUTPUT_SCHEMA
You must output a single JSON object conforming to this structure:
{
  "escalation_notice": "string or null",
  "violated_guardrail": {
    "clause_id": "string",
    "quoted_text": "string"
  },
  "violation_context": [
    {
      "timestamp_or_id": "string",
      "actor": "user | assistant | tool",
      "content": "string"
    }
  ],
  "severity_classification": {
    "level": "LOW | MEDIUM | HIGH | CRITICAL",
    "justification": "string"
  },
  "missing_evidence_notes": "string or null"
}

To adapt this template, replace the bracketed placeholders with your application's specific data. [VIOLATION_EVENT_DETAILS] should be a summary of the trigger event. [GUARDRAIL_POLICY_DOCUMENT] is the full text of your safety policies. [RELEVANT_USER_INTERACTION_LOG] is the transcript or log segment. [SEVERITY_CLASSIFICATION_RUBRIC] defines your internal severity levels. [OUTPUT_SCHEMA] can be replaced with your own schema, but the one provided is a strong starting point. The [RISK_LEVEL] placeholder allows your application to inject a pre-computed risk score to control the escalation notice. Always test this prompt with examples of both clear violations and edge cases where the evidence is thin or contradictory to ensure the model correctly identifies missing information rather than hallucinating it.

This prompt is designed to be called by an application after a guardrail violation has been detected by a separate monitoring system. The monitoring system should capture the raw violation context—the offending input, the guardrail rule that was triggered, and the model's response—and pass it to this prompt as structured input. Do not use this prompt for real-time intervention; it is an asynchronous evidence-packaging step that prepares a case for a human reviewer in a queue. The output is a JSON evidence packet that your application should validate, store, and attach to a review ticket.

Wire this prompt into a queue-based workflow. When a guardrail violation event is received, your application should: (1) assemble the [VIOLATION_CONTEXT] with the raw input, model output, triggered guardrail ID, and timestamp; (2) inject the relevant [GUARDRAIL_POLICY] text so the model can reference the exact rule; (3) call the model with a low temperature (0.0–0.2) to maximize factual consistency; and (4) validate the returned JSON against your evidence packet schema before enqueueing. If validation fails, retry once with the validation error message appended to the prompt as a correction hint. If the retry also fails, log the failure and create a manual-review ticket with the raw violation data so a human can package it. For model choice, a fast instruction-tuned model like GPT-4o or Claude 3.5 Sonnet is sufficient; this task requires instruction-following and structured output, not deep reasoning.

Implement a post-processing validation layer that checks: (a) the guardrail_id in the output matches the one in the input; (b) the severity field is one of your defined enum values; (c) the evidence_chain array contains at least one entry with a non-empty excerpt and source; and (d) the violation_summary is under 500 characters to keep review tickets scannable. Log every packaged evidence packet with the violation ID, the reviewer assigned, and the final adjudication outcome. This creates an audit trail for governance reviews and helps you measure whether the evidence packaging is actually helping reviewers make faster, more consistent decisions. Avoid wiring this prompt directly to any action that modifies user accounts or content; the output should only create a review item, never automate enforcement.