Streaming Input Safety Interrupt Prompt

This prompt is designed for safety engineers and platform operators who need to perform real-time safety classification on streaming user input, such as keystroke-level text or chunked audio transcripts. The primary job-to-be-done is to make an early-abort decision—interrupting a harmful request before the user finishes typing it—to stay within a strict latency budget. The ideal user is someone integrating this into a WebSocket proxy, a streaming API gateway, or a real-time inference pipeline where waiting for the full user message is too slow. You need this when your threat model includes adversarial users who gradually construct disallowed prompts, and your system must block the interaction mid-stream rather than generating a refusal after the fact.

You should not use this prompt for post-hoc content auditing, batch classification of stored logs, or evaluating complete, well-formed requests where the full context is available. It is also not a replacement for a full-input safety classifier; the partial-input risk assessment is inherently noisier and trades precision for speed. The prompt expects a [PARTIAL_INPUT] chunk, an optional [SESSION_HISTORY] for multi-turn probing detection, and a [LATENCY_BUDGET_MS] to enforce a hard timeout on the model's reasoning. The output is a structured [INTERRUPT_DECISION] with a binary block flag, a risk_score, and a reason code. Do not use this prompt for generating user-facing refusal messages; its sole purpose is to signal the application layer to sever the connection or clear the buffer.

Before deploying, you must calibrate the interrupt threshold against your specific safety taxonomy and latency requirements. A false positive here means dropping a benign user's connection mid-sentence, which is a severe user experience degradation. Implement a mandatory human-review sampling pipeline for all block decisions to measure precision, and pair this prompt with a full-input classifier that re-evaluates the completed message if the stream is not interrupted. The next step is to wire this prompt into your streaming middleware and configure the [LATENCY_BUDGET_MS] to be less than your end-to-end timeout.

This prompt template is designed to be wired into a streaming pipeline where user input arrives incrementally. The model evaluates each chunk as it arrives, classifying safety risk and signaling whether processing should continue or abort. The template uses square-bracket placeholders that your application must populate before each request: [POLICY_DEFINITIONS] contains your organization's specific harm categories and refusal criteria, [LATENCY_BUDGET_MS] sets the maximum allowed classification time per chunk, and [ABORT_THRESHOLD] defines the risk score above which the pipeline should interrupt processing immediately.

textCopy
SYSTEM:
You are a streaming safety classifier operating in a real-time pipeline. Your task is to evaluate each incoming text chunk for safety violations and return a structured classification decision within [LATENCY_BUDGET_MS] milliseconds.

SAFETY POLICIES:
[POLICY_DEFINITIONS]

CLASSIFICATION RULES:
1. Evaluate each chunk independently against all policy categories.
2. For partial or ambiguous inputs, assess risk based on what is present, not what might follow.
3. If a chunk contains clear policy-violating content, set abort_signal to true immediately.
4. If a chunk is benign but could be part of a larger harmful pattern, flag it as requires_context and continue.
5. Do not wait for complete input before signaling high-confidence violations.

OUTPUT SCHEMA:
Return a JSON object with these fields:
- chunk_index: integer (zero-based position of this chunk in the stream)
- risk_score: float between 0.0 and 1.0 (calibrated confidence that this chunk violates policy)
- primary_category: string or null (the most relevant policy category if risk_score > 0.3)
- abort_signal: boolean (true if processing should stop immediately)
- requires_context: boolean (true if this chunk needs surrounding chunks for accurate classification)
- partial_evidence: string or null (quote the specific text that triggered the classification)
- latency_ms: integer (actual classification time for this chunk)

ABORT THRESHOLD: [ABORT_THRESHOLD]
If risk_score exceeds [ABORT_THRESHOLD] and abort_signal is true, the pipeline must stop processing and return the current classification.

USER:
Chunk [CHUNK_INDEX]: [CHUNK_TEXT]

Previous chunks summary (if any): [PRIOR_CHUNKS_SUMMARY]

To adapt this template for your environment, replace [POLICY_DEFINITIONS] with your organization's specific harm taxonomy, including category names, definitions, and examples of violating and non-violating content. Set [LATENCY_BUDGET_MS] based on your end-to-end latency requirements—typical values range from 50ms to 200ms for real-time chat applications. Configure [ABORT_THRESHOLD] after calibrating against a labeled dataset; start conservatively at 0.7 and adjust based on false-positive and false-negative rates observed in production. The [PRIOR_CHUNKS_SUMMARY] field should be populated by your application layer with a concise summary of preceding chunks to provide context without exceeding token budgets. Before deploying, run this prompt through a regression test suite containing known safe inputs, adversarial examples, and boundary cases to verify that abort signals fire correctly and that partial-input classification does not produce excessive false positives on benign sentence fragments.

The Streaming Input Safety Interrupt Prompt is designed for a real-time processing loop, not a single request-response call. The application must manage a token buffer that accumulates user input as it arrives, periodically invoking the model to evaluate the partial content. The core harness requires three components: a token accumulator that buffers streaming input, a scheduler that triggers safety evaluations at configurable intervals (e.g., every N tokens or every M milliseconds), and an interrupt controller that can abort the upstream input stream and inject a safety response when a violation is detected. The prompt itself expects the accumulated partial text in the [PARTIAL_INPUT] placeholder and a [LATENCY_BUDGET_MS] constraint that tells the model how much inference time it can use before the system must make a gating decision.

The evaluation loop should follow a strict sequence. First, the accumulator appends new tokens to the buffer. Second, the scheduler checks whether the evaluation interval has elapsed—common configurations trigger every 50–100 tokens for text or every 200ms for voice transcription pipelines. Third, the harness calls the model with the current [PARTIAL_INPUT], [LATENCY_BUDGET_MS], and [RISK_THRESHOLD] parameters. The model must return a structured JSON object containing interrupt_signal (boolean), risk_category (string), confidence_score (float 0–1), and partial_evaluation_notes (string). Fourth, the interrupt controller inspects interrupt_signal: if true and confidence_score exceeds the configured [RISK_THRESHOLD], the system immediately stops accepting further input, flushes the buffer, and returns the safety response. If false or below threshold, the loop continues. Critical constraint: the model must never wait for input completion before evaluating—the entire value of this pattern is early interruption before a harmful request is fully articulated.

Validation and logging are essential because partial-input classification has inherently higher uncertainty than full-input classification. The harness should log every evaluation event with a session_id, buffer_position, tokens_evaluated, interrupt_signal, confidence_score, and latency_actual_ms. This telemetry enables offline analysis of false-positive interrupts (where the system aborted a benign request mid-stream) and false negatives (where a harmful request completed without interruption). For high-risk deployments, implement a dual-threshold strategy: a lower threshold triggers a soft interrupt that pauses input and requests human review, while a higher threshold triggers a hard abort with an immediate safety response. This prevents over-interruption in ambiguous cases while maintaining a safety floor. Model choice matters significantly here—smaller, faster models (e.g., 8B parameter class) are often preferred over larger models because latency predictability is more important than classification nuance when working with 200ms budgets.

Avoid wiring this prompt into a synchronous request chain where the user waits for each evaluation to complete before sending more input. The evaluation must happen concurrently with input streaming. If the model call exceeds the [LATENCY_BUDGET_MS], the harness should treat the timeout as a interrupt_signal: false with a logged warning, not as a safety failure. Never use this pattern as the sole safety layer—it is an upstream early-abort mechanism that should feed into a full-input classifier for final verification. The partial-input evaluation is intentionally aggressive to minimize harm exposure, so expect a higher false-positive rate than your full-input safety stack. Plan for human review queues to handle soft interrupts, and monitor the ratio of interrupts to completed sessions as a key health metric.