Cumulative Risk-Aware Conversation Termination Prompt

This prompt is designed for safety platform operators and abuse detection engineers who need to automate session termination decisions based on cumulative risk across an entire conversation. Single-turn safety classifiers miss multi-step adversarial strategies where risk accumulates gradually across probing, context poisoning, and incremental boundary pushing. This prompt evaluates the full session trajectory, decides when cumulative risk crosses an irreversible threshold, and produces a termination decision with policy justification, a user-facing closure message, and a structured post-termination review packet. Use this when your platform requires auditable, consistent termination decisions that hold up under internal review and external scrutiny.

The ideal deployment context includes a session-level risk scoring pipeline that feeds cumulative risk vectors into this prompt. You must provide the full conversation transcript, a pre-computed risk score trajectory, the applicable policy matrix, and the termination threshold configuration. The prompt expects structured inputs: [SESSION_TRANSCRIPT] with turn-by-turn metadata, [RISK_SCORE_TRAJECTORY] with per-turn scores and confidence intervals, [POLICY_MATRIX] mapping violation categories to severity levels, and [TERMINATION_THRESHOLD] defining the irreversible risk boundary. Without these inputs, the prompt cannot make reliable termination decisions. Do not use this prompt for single-turn content moderation, for systems where session context is not available, or for platforms that lack a defined policy matrix and review queue infrastructure.

Before deploying this prompt, verify that your upstream risk scoring pipeline produces calibrated confidence scores and that your policy matrix has been reviewed by legal and trust-and-safety stakeholders. The termination decision this prompt produces is only as sound as the risk signals feeding into it. Implement a human review override path for edge cases where the cumulative score is near the threshold or where the risk trajectory shows sudden spikes that may indicate scoring errors. Never deploy automated session termination without a false termination recovery path—users who are incorrectly terminated must have a clear appeal mechanism, and your operations team needs the structured review packet this prompt produces to resolve disputes efficiently.

This prompt template is designed to be deployed as a system-level instruction for a safety evaluation model that reviews full conversation histories. It does not generate user-facing responses directly; instead, it produces a structured termination decision payload that your application harness consumes. The template uses square-bracket placeholders for all dynamic inputs, including your organization's specific safety policies, risk thresholds, and session context. Copy this template, replace the placeholders with your concrete values, and integrate it into your safety evaluation pipeline.

textCopy
You are a session safety evaluator. Your task is to analyze the complete conversation history provided in [SESSION_CONTEXT] and determine whether cumulative risk has crossed an irreversible threshold requiring session termination.

## POLICIES
Evaluate the session against the following safety policies. A violation of any policy in the [CRITICAL_POLICIES] list is grounds for immediate termination. Repeated or escalating violations of policies in the [ESCALATING_POLICIES] list should trigger termination when the cumulative severity score exceeds [TERMINATION_THRESHOLD].

[CRITICAL_POLICIES]
[ESCALATING_POLICIES]

## RISK SCORING RULES
- Assign each policy violation a severity score from 1 (minor) to 10 (critical).
- Multiply severity by a recency factor: 1.0 for the most recent turn, decaying by 0.2 per prior turn.
- Sum weighted scores to produce a cumulative risk score.
- If any [CRITICAL_POLICIES] violation is detected, set the cumulative risk score to the maximum value regardless of other calculations.

## TERMINATION THRESHOLD
Termination threshold: [TERMINATION_THRESHOLD]

## OUTPUT SCHEMA
Return a valid JSON object with exactly this structure:
{
  "decision": "terminate" | "continue" | "escalate",
  "cumulative_risk_score": number,
  "violations": [
    {
      "turn_index": number,
      "policy_id": string,
      "severity": number,
      "recency_weight": number,
      "evidence": string,
      "category": "critical" | "escalating"
    }
  ],
  "termination_reason": string | null,
  "user_closure_message": string | null,
  "post_termination_review_packet": {
    "risk_timeline": string,
    "key_evidence_turns": [number],
    "policy_citations": [string],
    "recommended_action": string,
    "override_eligibility": boolean,
    "override_governance_note": string
  } | null
}

## CONSTRAINTS
- Do not fabricate violations. Only flag turns where evidence clearly matches a defined policy.
- If the cumulative risk score is below [TERMINATION_THRESHOLD] and no [CRITICAL_POLICIES] are violated, decision must be "continue".
- If decision is "terminate", the user_closure_message must be empathetic, non-accusatory, and must not reveal internal policy details or risk scores.
- If decision is "escalate", the post_termination_review_packet must be populated with sufficient detail for a human reviewer to make a final decision within [REVIEW_SLA_MINUTES] minutes.
- The override_eligibility field must be true only when the cumulative risk score is within [OVERRIDE_MARGIN] of the threshold and no critical policy violations are present.

## FALSE TERMINATION RECOVERY
If a prior termination decision is flagged as a false positive during review, the recovery path is: [RECOVERY_PATH]. Include this context when evaluating whether the current session resembles a known false-positive pattern.

## INPUT
[SESSION_CONTEXT]

After copying the template, replace each placeholder with concrete values from your safety policy system. The [CRITICAL_POLICIES] and [ESCALATING_POLICIES] placeholders should contain structured policy definitions with unique IDs, clear descriptions, and example violations. The [SESSION_CONTEXT] should be the full conversation history formatted with turn indices, roles, and content. Before deploying, validate that your termination threshold produces the expected decisions on a golden dataset of labeled sessions, and ensure your application harness can parse the JSON output schema without field mismatches. For high-stakes deployments, always route "escalate" decisions to a human review queue rather than automating termination.

This prompt is not a standalone safety filter; it is a decision endpoint in a larger safety platform. It should be invoked after each user turn by a session-level orchestrator that maintains the full conversation history, the cumulative risk score vector, and the policy configuration. The orchestrator is responsible for assembling the prompt's required inputs—[SESSION_HISTORY], [CUMULATIVE_RISK_VECTOR], [POLICY_CONFIG], and [OVERRIDE_STATE]—from upstream detection systems and policy stores. The prompt's output is a structured termination decision that downstream enforcement logic acts upon, not a direct user-facing message.

Validation and Enforcement: The model's JSON output must pass a strict schema validator before any action is taken. If the termination_decision field is not one of the allowed enum values (terminate, warn, restrict_tools, continue), or if required fields like policy_justification are missing, the response is rejected. On validation failure, implement a single retry with the validation error message injected into the prompt's [PREVIOUS_ERROR] placeholder. If the retry also fails, escalate to a human reviewer and default to the safest action configured for the current risk tier (typically restrict_tools or terminate). Never default to continue on a failed validation.

Logging and Audit Trail: Log the full prompt payload, the raw model response, the validated decision, and the enforcement action taken. This log entry becomes the core of the post-termination review packet. Include a unique session_id and decision_id in every log. For terminate decisions, automatically generate a review ticket in your trust-and-safety queue with the logged evidence attached. This ensures that every automated termination is auditable and reversible by a human reviewer without requiring them to reconstruct the session from scratch.

Human Override Governance: The [OVERRIDE_STATE] input allows authorized human operators to pre-empt or reverse automated decisions. If an override is active (e.g., a safety analyst has marked a session as under_review or override_continue), the prompt must acknowledge this state and produce a decision that respects the override while still documenting what the automated system would have recommended. This dual-output pattern—

automated recommendation" vs. "effective decision"—preserves the audit trail and prevents the override from masking systemic failures in the risk scoring pipeline."

Model Choice and Latency: This prompt requires strong instruction-following and structured output reliability. Use a model with proven JSON mode or function-calling capabilities. Latency is critical because this decision gates the user's next interaction. If the model call exceeds a 2-second timeout, fall back to a cached risk-threshold decision matrix that maps the current [CUMULATIVE_RISK_VECTOR] to a pre-configured action. Log the timeout and fallback decision. Do not leave the user waiting indefinitely for a safety decision.

What to Avoid: Do not wire this prompt directly to a user-facing chat interface. The user_facing_closure_message field is a draft for review, not a message to send unmodified. Always route termination messages through a templating layer that can adjust tone, apply branding, and strip any internal rationale before display. Do not use this prompt for single-turn content moderation; it is designed for cumulative session risk and will produce false positives on isolated benign turns if used without the session risk vector context.