Session Context Risk Vector Extraction Prompt

This prompt is for ML engineers and safety platform builders who need to convert raw, multi-turn conversation history into a structured, typed feature vector for downstream session-level safety classifiers. Single-turn risk evaluation misses adversarial strategies that unfold across multiple messages, such as gradual jailbreak attempts, context poisoning, and refusal override probing. This prompt extracts risk signals that only become visible when you analyze the full session arc: topic drift toward disallowed subjects, accumulation of sensitive entities, repeated instruction hierarchy violations, and patterns of boundary testing. Use this prompt when you are building a feature extraction layer that feeds a classifier, a risk scoring model, or an escalation decision system.

The ideal input is a complete, unredacted conversation history with clear role delineation (system, user, assistant, tool) and turn-level timestamps or sequence markers. The prompt expects a defined [RISK_TAXONOMY] mapping your organization's policy categories to numeric identifiers, and an [OUTPUT_SCHEMA] specifying the exact typed feature vector your downstream model consumes. Without these, the extraction will be generic and unreliable. The prompt is designed to be stateless per invocation—it processes the entire session in one pass rather than maintaining state across calls—making it suitable for batch processing, async review queues, and session-close triggers.

Do not use this prompt for real-time single-turn moderation, generating user-facing refusal messages, or making final policy decisions without a downstream model or human review step. It is a feature extraction component, not a decision engine. If you need per-turn classification, use a single-turn safety classifier. If you need to generate a refusal message to the user, use a refusal generation prompt. If you need to terminate a session or escalate to human review, wire this prompt's output into a separate decision prompt that consumes the feature vector and applies your organization's risk thresholds. The extraction prompt itself should never directly trigger user-visible actions.

Before deploying, validate the output against your [OUTPUT_SCHEMA] using a strict JSON Schema validator. Common failure modes include missing fields when the session lacks certain risk indicators, type mismatches when the model miscounts entities, and hallucinated risk signals when the conversation is benign but the model over-extrapolates. Build eval datasets with known adversarial sessions, benign complex sessions, and edge cases like empty conversations or single-turn interactions. Measure field-level precision and recall against human-annotated ground truth before trusting this extraction in a production safety pipeline.

This prompt template is designed to be the core instruction set for an LLM acting as a session-level feature extractor. Its job is not to refuse or respond to the user, but to analyze a complete conversation history and produce a typed, machine-readable risk vector. You will replace each square-bracket placeholder with your specific safety taxonomy, risk definitions, and the exact JSON schema your downstream classifier expects. The prompt is structured to enforce strict output formatting and to ground every risk dimension in specific evidence from the conversation turns.

textCopy
You are a session-level safety feature extractor. Your output is consumed by a downstream classification model. Do not generate a user-facing response. Analyze the provided conversation history and output a single JSON object conforming to the schema below.

[SAFETY_POLICY_DEFINITIONS]

[RISK_DIMENSION_DEFINITIONS]

[OUTPUT_SCHEMA]

[CONVERSATION_HISTORY]

[EXAMPLES]

[CONSTRAINTS]

To adapt this template, start by defining your safety policies and risk dimensions in the bracketed sections. [SAFETY_POLICY_DEFINITIONS] should list the categories of disallowed content (e.g., self-harm, child safety, regulated advice). [RISK_DIMENSION_DEFINITIONS] must operationalize the features you need, such as 'topic drift toward disallowed categories,' 'cumulative count of refused override attempts,' or 'presence of instruction hierarchy violations.' The [OUTPUT_SCHEMA] placeholder is critical: provide a strict JSON schema with typed fields, enum constraints, and required properties. The [CONSTRAINTS] section should include rules like 'cite the specific turn index for every extracted feature' and 'set the confidence score to 0.0 if no evidence is found.' Always include a few [EXAMPLES] of input histories and their correct output vectors to anchor the model's behavior.

Before deploying this prompt into a production harness, validate that the model's output strictly conforms to your schema. Common failure modes include the model adding explanatory text outside the JSON block, hallucinating turn indices that don't exist, or defaulting to a high confidence score when evidence is weak. Your implementation should include a post-processing validation step that parses the JSON, checks it against the schema, and retries with a repair prompt if validation fails. For high-stakes safety applications, the extracted feature vector should be treated as a signal for a deterministic classifier or a human reviewer, not as the final decision itself.

This prompt is a feature extraction step, not a decision step. Its job is to consume a full conversation history and produce a structured, typed risk feature vector. That vector should feed a downstream classifier, risk scoring model, or escalation engine. Do not ask this prompt to make allow/deny decisions, generate user-facing refusal messages, or decide session termination. Keep extraction and decision separate so you can version the feature schema, calibrate thresholds, and audit decisions independently.

Wire the prompt into your application as a stateless transform. The caller provides the full session transcript in [CONVERSATION_HISTORY] and receives a JSON payload matching the [OUTPUT_SCHEMA]. Validate the output before it reaches any downstream model: check that all required fields are present, numeric scores fall within expected ranges, enum values match allowed sets, and evidence spans reference actual turn indices from the input. Reject malformed outputs and retry once with a stricter schema reminder. If the retry also fails, log the raw output and emit a null feature vector with an extraction_failure flag so the pipeline can fall back to single-turn scoring or escalate for human review.

Model choice matters here. Use a model with strong instruction-following and structured output support. The prompt requires precise JSON typing, turn-index accuracy, and consistent enum selection across long contexts. If your production stack supports tool calling or structured output modes, enforce the schema at the API level rather than relying on prompt text alone. For high-throughput pipelines, consider batching session extracts and caching the feature vectors alongside session state so downstream classifiers can re-score without re-extraction.

Logging and observability are critical because this prompt sits upstream of safety decisions. Log every extraction attempt with: session ID, model version, prompt version, extraction latency, validation pass/fail, and a hash of the output feature vector. If a downstream classifier escalates a session, the logged feature vector is your audit artifact. It tells reviewers exactly what signals were extracted and why the system reacted. Without this log, you cannot debug false escalations or missed adversarial sequences.

Avoid wiring this prompt directly to a user-facing refusal or termination action. The feature vector it produces may contain sensitive inferences about user intent, probing patterns, or policy violations. Route it through a calibrated risk scoring model first, apply configurable thresholds, and require human approval for irreversible actions like session termination or account restriction. The extraction prompt is a sensor, not a judge.