Evidence Package Assembly Prompt for Human Review

This prompt is designed for the handoff point between an automated guardrail detection system and a human review queue. Its job is to eliminate the 'context hunt' that slows down human adjudicators. When a detection system flags a violation, the raw signal is often just a score and a snippet. A reviewer needs the full conversation history, the specific policy clause that was violated, the severity classification, and a structured recommendation to make a fast, consistent decision. This prompt assembles those disparate pieces into a single, reviewer-ready evidence package, ensuring the human can adjudicate the violation without opening five other systems.

The ideal user is a trust and safety engineer, compliance officer, or operations lead who is building a human-in-the-loop (HITL) escalation pipeline. The required inputs are a structured violation detection record (containing the violating excerpt and severity), the full conversation context, and the relevant policy library. The prompt enforces a completeness validation step, refusing to produce a package if critical evidence is missing. This prevents 'under-evidenced' escalations that waste reviewer time and erode trust in the automation. It is designed to be wired into a middleware layer that fetches context from your database and policy store before calling the LLM.

Do not use this prompt for real-time blocking decisions where latency is measured in milliseconds. Evidence assembly adds a non-trivial delay and is meant for asynchronous review queues. Similarly, do not use it when the violation is pre-authorized for automated remediation (e.g., a hard block on known malicious patterns). If you skip the human review step, you are generating a structured packet that no one will read, wasting compute. Finally, avoid using this prompt if your detection system does not reliably capture the violating excerpt; the prompt's completeness check will cause it to fail closed, which is safe but will stall your pipeline.

This prompt template is the core instruction set for an AI system that must transition from detection to adjudication. It takes raw violation data and transforms it into a structured, reviewer-ready case file. The template is designed to be pasted directly into your system prompt or a dedicated API call, with square-bracket placeholders representing the dynamic data your application must inject at runtime. The strict JSON output contract ensures the resulting evidence package can be parsed and routed into a review queue without manual reformatting.

textCopy
You are a precise evidence package assembler for a trust and safety review queue. Your task is to compile a complete, structured adjudication packet from the provided violation data. You must not add, assume, or infer any information not present in the input. If required evidence is missing, you must flag it explicitly rather than fabricate it.

## INPUT DATA
- Violation Record: [VIOLATION_JSON]
- Conversation/Event Log: [FULL_CONTEXT_LOG]
- Relevant Policy Document: [POLICY_TEXT]
- User/Account Metadata: [USER_METADATA_JSON]

## OUTPUT SCHEMA
You must output a single, valid JSON object conforming to this exact schema:
{
  "case_id": "string (from Violation Record)",
  "status": "ready_for_review",
  "violation_summary": {
    "policy_violated": "string (exact policy name)",
    "severity": "string (CRITICAL | HIGH | MEDIUM | LOW)",
    "detection_timestamp": "string (ISO 8601)",
    "violation_type": "string (e.g., 'toxic_output', 'prompt_injection')"
  },
  "evidence_package": {
    "conversation_excerpt": {
      "pre_context": ["string (3-5 messages before violation)"],
      "violating_content": "string (the exact message or action)",
      "post_context": ["string (2-3 messages after violation)"]
    },
    "policy_citation": {
      "relevant_clause": "string (verbatim text from policy)",
      "clause_reference": "string (e.g., 'Section 3.2 - Harmful Content')"
    },
    "key_entities": [
      {
        "entity_type": "string (e.g., 'user_id', 'session_id')",
        "entity_value": "string"
      }
    ]
  },
  "suggested_remediation": "string (one clear, actionable next step based on policy)",
  "completeness_check": {
    "all_required_fields_present": true,
    "missing_evidence": ["string (list any missing items, empty if complete)"]
  }
}

## CONSTRAINTS
- Do not include any text outside the JSON object.
- The `violating_content` must be a verbatim copy from the log.
- If the policy text does not contain a clear citation, set `relevant_clause` to "No exact match found in provided policy" and flag this in `missing_evidence`.
- If the severity in the input is not one of the four allowed values, default to "HIGH" and note the discrepancy in `missing_evidence`.

To adapt this template, replace the placeholders with your system's live data. The [VIOLATION_JSON] should be the structured output from your upstream detection prompt. The [FULL_CONTEXT_LOG] is the raw, unedited interaction that triggered the detection. The [POLICY_TEXT] must be the canonical policy document, not a summary, to enable accurate citation. The [USER_METADATA_JSON] provides reviewer context like account standing. After the model returns the JSON, your application harness must validate it against the schema before posting it to the review queue. If the completeness_check.missing_evidence array is not empty, the case should be flagged for pre-review enrichment, not sent directly to a human adjudicator.

The Evidence Package Assembly prompt is not a standalone artifact; it is a critical component in a human-in-the-loop adjudication pipeline. Its output must be treated as a structured data payload that feeds directly into a review queue system. The primary goal of the harness is to guarantee that every escalation presented to a human reviewer is complete, well-formed, and actionable, preventing the waste of reviewer time on under-evidenced or malformed packets. This means the application code wrapping the prompt is responsible for input sanitization, output validation, and state management, not the prompt itself.

Validation and the Retry Loop: Before an evidence package ever reaches a human, the application must validate the model's output against a strict schema. Use a library like jsonschema in Python or zod in TypeScript to enforce the presence of required fields: violation_id, policy_citation, conversation_excerpt, severity_classification, and suggested_remediation. If validation fails, do not immediately escalate. Instead, implement a retry loop with error forwarding. Re-invoke the model, appending the raw output and the specific validation error (e.g., 'Missing required field: policy_citation') to the prompt as a correction instruction. Limit this loop to a maximum of 2 retries to control latency and cost. If validation still fails after retries, log the raw output as a malformed_escalation event and create a minimal manual-review ticket for an on-call engineer, as this indicates a systemic prompt or model failure.

Logging, Auditing, and Human Routing: Every step of this process must be logged for governance and debugging. Capture the input guardrail trigger, the model's raw response, the validation result, and the final adjudication outcome in an immutable audit log. When the package is valid, the harness should push it to a human review queue with a structured payload that includes the validated evidence package and a set of decision options (e.g., OVERRIDE_AND_CONTINUE, SUSPEND_ACTION, FALSE_POSITIVE). The routing logic can use the severity_classification field to assign priority. For high-severity violations, the harness should trigger an immediate notification (e.g., PagerDuty alert) in addition to the queue entry. Avoid the temptation to let the model make the final decision; the harness's job is to prepare the perfect packet for a human judge, not to automate the verdict.