Turn History Safety Annotation Prompt for Refusal Systems

This prompt is for safety platform builders who need to annotate every turn in a multi-turn conversation with structured safety metadata. The primary job-to-be-done is producing a JSON array of turn annotations, each containing a safety classification, risk score, and policy citation. Downstream refusal logic, audit systems, and session-risk evaluators consume this structured history to make consistent, evidence-backed refusal decisions. The ideal user is an engineering lead or safety engineer integrating this prompt into a context-aware refusal pipeline where prior turn classifications must be referenced before deciding whether to refuse the current request.

Use this prompt when you are building a system that requires cumulative safety context across turns. For example, a user might first ask a benign question, then gradually rephrase it into a disallowed request over several turns. A single-turn classifier would miss this pattern, but this prompt's structured history allows downstream logic to detect the escalation. The prompt assumes you already have defined safety policies and a conversation transcript with clear speaker roles. It is not a replacement for a real-time blocking filter, a single-turn safety classifier, or a policy definition engine. If you need to block harmful content before the model responds, use a pre-response guard model instead. If you need to define what constitutes a policy violation, start with a policy boundary definition prompt before wiring in this annotation step.

Do not use this prompt when latency is the primary constraint. Annotating every turn adds processing overhead that may be unacceptable for real-time chat applications requiring sub-second response times. It is also the wrong tool if you lack a defined safety policy taxonomy—the prompt will produce inconsistent, ungrounded classifications without clear policy categories to reference. Before deploying, ensure you have a test suite of multi-turn conversations with expected annotations, and plan to run consistency evals across model updates. The next step after reading this section is to review the prompt template and implementation harness to understand how to wire this into your refusal pipeline.

This template is designed to be dropped directly into your safety annotation pipeline. It instructs the model to process a full conversation transcript turn-by-turn, producing a structured JSON array that downstream refusal systems can consume. The prompt enforces strict output formatting, requires policy citations from your taxonomy, and demands concise rationales—making the annotations auditable and machine-readable rather than conversational.

textCopy
Annotate the following multi-turn conversation transcript with safety classifications, risk scores, and policy citations. Return a strict JSON array where each element corresponds to one turn in order.

[POLICY_TAXONOMY]

[CONVERSATION_TRANSCRIPT]

For each turn, produce an object with these fields:
- "turn_index": integer matching the input turn order
- "speaker": string, the speaker label from the transcript
- "safety_classification": one of [SAFE_CLASSIFICATION_LABELS]
- "risk_score": float between 0.0 and 1.0
- "policy_citations": array of policy IDs from the taxonomy that apply, empty array if none
- "rationale": string, one-sentence justification referencing specific policy language

[OUTPUT_SCHEMA]

[CONSTRAINTS]

To adapt this template, replace each square-bracket placeholder with your operational values. [POLICY_TAXONOMY] should contain your organization's safety policies with unique IDs and descriptions. [SAFE_CLASSIFICATION_LABELS] must be a closed set of labels like safe, disallowed, ambiguous, or requires_review. [OUTPUT_SCHEMA] can be a JSON Schema definition or a reference to your validation contract. [CONSTRAINTS] should include rules like 'risk_score must be 0.0 for safe turns' or 'rationale must cite a policy ID when classification is disallowed'. Always validate the output array length matches the input turn count before storing annotations—mismatches indicate a model failure that requires retry or escalation.

This prompt is not a user-facing endpoint. It is an internal safety infrastructure component that runs after each user turn and before the assistant generates a response. The annotation output is consumed by downstream refusal logic—never exposed to end users. In a typical architecture, you call this prompt inside a pre-response safety pipeline, store the annotated turn array in a session state object keyed by session ID, and let the refusal router read the latest annotation to decide whether to refuse, escalate, or respond. For stateless architectures, serialize the annotation array into a compact string and pass it as a safety context preamble on the next turn so the refusal system retains awareness of prior risk signals without maintaining server-side session state.

Validation and retry discipline is critical because a malformed annotation silently breaks downstream refusal decisions. After each invocation, validate that the model output is parseable JSON matching the expected schema: a turns array where each entry contains turn_index, safety_classification, risk_score, policy_citations, and rationale. On JSON parse failure, retry once with a stricter constraint instruction appended to the prompt—for example, 'You MUST output only valid JSON. No markdown fences, no commentary, no trailing text.' If the retry also fails, log the raw output with the session ID, flag the session for human review, and apply the most restrictive default refusal policy (treat the turn as high-risk). Never silently proceed with a failed annotation.

Model choice and latency matter in production. This prompt works well with fast, instruction-following models (GPT-4o-mini, Claude 3.5 Haiku, or equivalent) because it runs on every turn and must not add unacceptable latency to the user experience. If you are already calling a larger model for response generation, consider running this annotation on a smaller, cheaper model in parallel or as a pre-check. Tool use is not required for this prompt—it is a pure classification and annotation task—but you may want to expose a log_annotation tool if your observability stack expects structured events rather than raw prompt outputs. RAG is not applicable here; the prompt operates on the conversation history you provide, not on external knowledge retrieval.

Downstream wiring is where most teams make mistakes. The refusal router should read only the latest annotation's risk_score and safety_classification fields to make its decision. Do not feed the full annotation text into the assistant prompt—that leaks safety infrastructure into the user-facing response path. Instead, maintain a clean separation: the annotation pipeline writes to session state, the refusal router reads from session state, and the assistant prompt receives only the refusal decision (refuse, escalate, or proceed) plus any safe-alternative guidance. Logging should capture the full annotation payload per turn for auditability, but those logs belong in your safety monitoring system, not in the conversation transcript the user can see. Before shipping, test the full pipeline end-to-end with multi-turn adversarial scenarios to confirm that annotation failures trigger the correct default refusal behavior rather than allowing unsafe responses through.