Incomplete Input Graceful Degradation Prompt

This prompt is a decision-layer component for production chat and voice systems that must handle truncated, noisy, or partially received user messages without hallucinating or silently dropping the turn. The primary job-to-be-done is to evaluate an incomplete or degraded [INPUT] against the available [SESSION_CONTEXT] and output a structured degradation decision. The ideal user is an AI engineer or technical product manager integrating this prompt into a real-time inference pipeline where network interruptions, ASR errors, streaming cutoffs, or client-side bugs are expected failure modes. Required context includes the raw partial input, the last N turns of conversation history, and any active system state such as pending tool calls or unfilled slots.

Use this prompt when the system cannot guarantee complete user input and must choose between three paths: responding with available partial understanding, requesting targeted clarification, or safely deferring with a logged rationale. It is appropriate for voice assistants recovering from endpointing errors, streaming chat UIs receiving mid-edit messages, and copilots handling interrupted multi-step workflows. The prompt is designed to prevent the two most common production failures in these scenarios: the model hallucinating a response to garbled input, and the system silently dropping the user's turn without any observability artifact. The structured output includes a decision field (respond_partial, request_clarification, or defer), a confidence score, and a rationale string suitable for logging and debugging.

Do not use this prompt when the input is known to be complete and well-formed, or when the system's latency budget cannot tolerate an additional classification step before the main response generation. It is also not a substitute for upstream input validation, ASR confidence filtering, or client-side input buffering—those layers should reduce the frequency of incomplete input reaching this prompt. In high-risk domains such as healthcare or finance, the defer decision must trigger a human review queue rather than silently dropping the turn. The prompt is not designed to repair the input itself; pair it with a dedicated repair prompt if reconstruction is needed before acting on partial understanding.

This prompt template acts as a pre-processing classifier for production chat systems that receive truncated, noisy, or partially received user messages. Instead of passing incomplete input directly to your main assistant and hoping for the best, this prompt forces an explicit degradation decision: respond with available partial understanding, request clarification, or safely defer. The structured output includes a decision code, confidence score, and rationale suitable for logging and observability, making it easy to monitor how often your system degrades and why.

textCopy
SYSTEM:
You are an input quality classifier for a production chat system. Your job is to evaluate whether a user message is complete enough to process or requires degradation handling.

## Input
- [USER_MESSAGE]: The raw user input, which may be truncated, noisy, or partially received.
- [SESSION_CONTEXT]: Prior conversation turns, active intents, and pending actions from the current session.
- [EXPECTED_SLOTS]: A list of required information slots for the current conversation phase, if applicable.

## Classification Rules
1. **COMPLETE**: The message is semantically complete and actionable. No degradation needed.
2. **PARTIAL_ACTIONABLE**: The message is incomplete but contains enough information to take a useful partial action or respond with high confidence.
3. **PARTIAL_CLARIFY**: The message is incomplete and requires clarification before proceeding. The missing information is specific and askable.
4. **UNRECOVERABLE**: The message is too fragmented, noisy, or ambiguous to recover. Defer or escalate.

## Constraints
- Do not guess missing information. If a required slot is unfilled, classify as PARTIAL_CLARIFY or UNRECOVERABLE.
- If [SESSION_CONTEXT] provides strong evidence for the likely intent, you may classify as PARTIAL_ACTIONABLE but must note the assumption in rationale.
- For [RISK_LEVEL]=HIGH, prefer PARTIAL_CLARIFY or UNRECOVERABLE over PARTIAL_ACTIONABLE.
- Confidence must reflect genuine certainty, not model fluency.

## Output Schema
Return ONLY valid JSON with no additional text:
{
  "decision": "COMPLETE" | "PARTIAL_ACTIONABLE" | "PARTIAL_CLARIFY" | "UNRECOVERABLE",
  "confidence": 0.0-1.0,
  "rationale": "Brief explanation of why this decision was reached, citing specific evidence from the input or session context.",
  "missing_information": ["list of specific missing slots or unclear elements"],
  "suggested_action": "What the downstream system should do: respond, ask for [specific clarification], or escalate."
}

## Examples
[EXAMPLES]

USER_MESSAGE: [USER_MESSAGE]
SESSION_CONTEXT: [SESSION_CONTEXT]
EXPECTED_SLOTS: [EXPECTED_SLOTS]
RISK_LEVEL: [RISK_LEVEL]

Adaptation guidance: Replace bracketed placeholders with your application's actual values. [EXAMPLES] should include 3-5 few-shot examples covering each decision type with your domain's actual message patterns. For voice assistant deployments, add a [LATENCY_BUDGET_MS] constraint and tune examples for ASR error patterns. For regulated domains, set [RISK_LEVEL] to HIGH and add a [REGULATORY_CONTEXT] field describing compliance requirements. Wire this prompt as a lightweight classifier step before your main response generation—it should run on a fast model to avoid adding latency to the critical path.

Validation and evals: Test this prompt against a golden dataset of 50+ incomplete inputs with known correct decisions. Measure precision and recall per decision class, with special attention to false PARTIAL_ACTIONABLE classifications that could produce incorrect responses. Log every decision with the full input, session context, and rationale for production observability. Set up an alert if the UNRECOVERABLE rate spikes, as this often indicates upstream ASR or input pipeline issues. For high-risk workflows, route UNRECOVERABLE decisions to a human review queue rather than attempting automated recovery.

What to avoid: Do not use this prompt as a substitute for proper input validation in your application layer. Do not skip logging—the rationale field is your primary debugging tool when users report confusing responses. Do not set confidence thresholds without calibrating against your specific error tolerance; a 0.7 threshold that works for casual chat will fail for healthcare or finance. Finally, do not let the classifier become a bottleneck—if latency exceeds 200ms, consider caching session context or using a smaller model for this step.

The Incomplete Input Graceful Degradation Prompt is designed to sit at a critical decision point in your input processing pipeline: after you've received user input but before you've committed to a full intent classification, retrieval query, or agent action. The prompt receives the partial or noisy input, any available session context, and a set of degradation options you define. Its job is to output a structured decision—respond with partial understanding, request clarification, or safely defer—along with a rationale that your observability stack can log. This is not a prompt you fire-and-forget; it must be wrapped in application logic that respects the decision, enforces timeouts, and prevents the system from acting on low-confidence partial interpretations without explicit confirmation.

Wire the prompt into your application as a pre-processing gate. When your input buffer receives a message that is truncated (e.g., a voice endpoint fired mid-utterance, a chat message arrived with a partial: true flag, or a streaming connection dropped packets), call this prompt before your main intent router or agent loop. Pass the raw partial text as [PARTIAL_INPUT], the last N turns of conversation as [SESSION_CONTEXT], and your system's available degradation actions as [DEGRADATION_OPTIONS]—for example, ["respond_with_partial_understanding", "ask_for_clarification", "defer_with_fallback_message", "wait_for_more_input"]. The model returns a JSON object with decision, confidence, rationale, and optionally clarification_question or partial_response. Your harness must validate this JSON against a strict schema before acting on it. If validation fails, retry once with a repair prompt; if it fails again, fall back to a safe default (typically defer_with_fallback_message). Log every decision and rationale to your observability platform so you can measure how often degradation occurs, which degradation paths users tolerate, and whether your endpointing or buffering logic needs tuning.

Model choice matters here. This prompt requires strong instruction-following and reliable structured output, so prefer models with native JSON mode or function-calling support (e.g., GPT-4o, Claude 3.5 Sonnet with tool use, or Gemini with controlled generation). Set temperature low (0.0–0.2) to minimize decision variance. If you're running on a streaming voice pipeline with tight latency budgets, consider hosting a smaller fine-tuned model dedicated to this single classification task rather than burning a large-model call on every partial utterance. For high-risk domains where a wrong degradation decision could cause user harm—such as healthcare intake or financial transaction confirmation—add a human review step when confidence falls below your calibrated threshold. Wire the rationale field into your audit trail so reviewers can understand why the system chose to proceed, clarify, or defer. Finally, build an eval harness that tests this prompt against a golden dataset of partial utterances with known correct degradation decisions, measuring precision and recall per degradation class, and run it as a gate before any prompt or model change reaches production.