Session Risk Report Generation Prompt for Review Queues

This prompt is for trust-and-safety operations teams who need to convert raw, multi-turn session risk scores into a structured review packet that a human reviewer can act on. It takes automated scoring outputs—cumulative risk scores, turn-level violation flags, and policy triggers—and produces a narrative summary with a risk timeline, key evidence turns, policy citations, and recommended actions. The primary job-to-be-done is creating a consistent, auditable brief that sits between automated detection and human decision-making, ensuring reviewers have exactly the information they need without reading the full session transcript.

Use this when your automated detection pipeline has flagged a session for review and you need a standardized report format that reduces reviewer cognitive load and decision variance. The prompt expects structured input: a session ID, a cumulative risk score, a list of turn-level risk events with timestamps and policy tags, and any confidence or ambiguity metadata from upstream classifiers. It is not designed for real-time intervention or inline chat moderation. It is a post-session or near-real-time report generation step that assumes the detection system has already made a preliminary escalation decision. If you need a prompt that decides whether to escalate, use the Session Risk Escalation Path Decision Prompt instead.

Do not use this prompt when the input lacks structured risk scores or turn-level evidence, when the reviewer needs the full transcript rather than a summary, or when the decision requires legal or medical expertise beyond policy enforcement. The output is a decision-support artifact, not a final determination. Always route the generated report to a human reviewer for the final action. For regulated domains, ensure the report includes an evidence trail that links each policy citation to a specific turn and that the reviewer's decision is logged separately from the AI-generated summary.

This template is designed to be the final step in an automated session-risk pipeline. It takes the raw output from upstream classifiers—cumulative risk scores, detected probing patterns, policy violation ledgers, and tool-access denial events—and synthesizes them into a single, human-readable review packet. The goal is to give a trust-and-safety operator everything they need to make a decision without hunting through logs. Replace every square-bracket placeholder with data from your own risk scoring services before sending this prompt to the model.

textCopy
You are a session risk report generator for a trust-and-safety operations team. Your task is to produce a structured review packet from automated session risk scoring data.

## INPUT DATA
- Session ID: [SESSION_ID]
- User ID: [USER_ID]
- Session Duration: [SESSION_DURATION]
- Total Turns: [TOTAL_TURNS]
- Cumulative Risk Score: [CUMULATIVE_RISK_SCORE] (scale: [RISK_SCALE_MIN]-[RISK_SCALE_MAX])
- Risk Score Trajectory: [RISK_TRAJECTORY]
- Escalation Triggers Fired: [ESCALATION_TRIGGERS]
- Detected Probing Patterns: [DETECTED_PATTERNS]
- Policy Violation Ledger: [POLICY_VIOLATION_LEDGER]
- Tool Access Denial Events: [TOOL_ACCESS_DENIAL_EVENTS]
- Context Poisoning Flags: [CONTEXT_POISONING_FLAGS]
- Session Termination Status: [TERMINATION_STATUS]

## OUTPUT SCHEMA
Generate a JSON object with the following structure. Do not include any text outside the JSON.
{
  "packet_id": "string, a unique ID for this review packet",
  "session_summary": {
    "session_id": "string",
    "risk_level": "string, one of: LOW, MEDIUM, HIGH, CRITICAL",
    "recommended_action": "string, one of: DISMISS, REVIEW, ESCALATE, TERMINATE_AND_REPORT",
    "summary_sentence": "string, a one-sentence executive summary of the session risk"
  },
  "risk_timeline": [
    {
      "turn_number": "integer",
      "turn_risk_score": "number",
      "key_event": "string, description of what happened this turn",
      "policy_citations": ["string, policy IDs violated"]
    }
  ],
  "key_evidence": [
    {
      "turn_number": "integer",
      "user_message_excerpt": "string, a short, verbatim excerpt from the user",
      "risk_indicator": "string, why this excerpt is risky"
    }
  ],
  "policy_violation_summary": [
    {
      "policy_id": "string",
      "violation_count": "integer",
      "severity": "string, one of: MINOR, MODERATE, SEVERE"
    }
  ],
  "detected_adversarial_patterns": [
    {
      "pattern_name": "string",
      "confidence": "number between 0 and 1",
      "evidence_turns": ["integer, list of turns supporting this pattern"]
    }
  ],
  "audit_trail": {
    "completeness_check": "boolean, true if all required fields are populated",
    "missing_data_notes": ["string, list any fields that were missing or null in the input"]
  }
}

## CONSTRAINTS
- If any input field is null or missing, note it in `audit_trail.missing_data_notes` and set `completeness_check` to false.
- Base the `risk_level` and `recommended_action` strictly on the provided scores and triggers, not on your own judgment of the user's intent.
- All `user_message_excerpt` values must be verbatim from the input data; do not paraphrase.
- If the session was terminated, the `recommended_action` must be TERMINATE_AND_REPORT.

To adapt this template, start by mapping your upstream risk scoring fields to the placeholders. The [POLICY_VIOLATION_LEDGER] should be a structured list of per-turn violations, and [DETECTED_PATTERNS] should come from your multi-turn probing detection system. If your risk pipeline doesn't produce a specific field, pass an explicit null so the model can flag it in the audit trail. For high-stakes domains, always route the generated packet to a human review queue and log the raw model output alongside the final reviewer decision for future calibration.

The session risk report prompt is not a standalone artifact—it is a component in a larger safety review pipeline. The prompt expects a structured [SESSION_RISK_DATA] payload that upstream classifiers produce, including cumulative risk scores, turn-by-turn violation flags, and extracted evidence. Before the prompt ever runs, validate that the input payload conforms to the expected schema: required fields such as session_id, risk_trajectory, violation_ledger, and escalation_triggers must be present and non-null. If the upstream scoring system cannot produce a complete payload, the pipeline should short-circuit with a DATA_INCOMPLETE error rather than feeding partial data into the report generator and producing a misleading summary.

Wire the prompt into an application harness that enforces a strict output contract. After the model returns a response, parse the output against the [OUTPUT_SCHEMA]—typically a JSON object containing report_id, risk_summary, timeline, key_evidence_turns, policy_citations, recommended_actions, and completeness_checks. Run a validator that confirms every required field is present, evidence turns reference actual turn indices from the input session, policy citations map to a known policy registry, and recommended actions are drawn from an allowed enum (CONTINUE, WARN, RESTRICT_TOOLS, HUMAN_REVIEW, TERMINATE). If validation fails, retry once with the validation errors appended to the prompt as [CONSTRAINTS] feedback. If the second attempt also fails, log the failure, flag the session for manual review, and do not surface an unvalidated report to a human reviewer.

Logging and audit trail requirements are non-negotiable for this workflow. Every report generation event should write an immutable log entry containing: the input payload hash, the model and prompt version used, the raw model output, the validation result, any retry attempts, and the final report that reached the review queue. This audit trail serves two purposes: it enables post-incident review when a reviewer questions a report's accuracy, and it provides the evidence chain required for compliance reviews. Store these logs in a tamper-evident system and retain them according to your organization's data governance policy. Do not log raw session transcripts in the same system if they contain PII or sensitive user content—instead, log a content hash and store the transcript in a separate access-controlled store.

Human review integration is the final stage. When the validated report enters the review queue, attach the report alongside the original session transcript and a reviewer decision form. The form should capture the reviewer's action (uphold, override, escalate), any notes, and a timestamp. Feed reviewer decisions back into the system: upheld reports confirm the prompt's output quality, overrides should trigger a review of the upstream risk scoring thresholds, and escalations should update the session risk model's training data. Avoid the common failure mode of treating the AI-generated report as the final word—the report is a decision support artifact, and the human reviewer remains the authority. If your review queue volume exceeds human capacity, invest in better upstream classifiers and threshold tuning rather than removing the human from the loop for high-risk sessions.