Malformed Query Detection and Rejection Prompt Template

This prompt acts as a pre-retrieval gatekeeper for RAG systems. Its job is to classify a user query as valid or malformed before any embedding, vector search, or keyword retrieval is executed. Use it when you need to reject input that is gibberish, empty, a copy-paste artifact, or so structurally broken that retrieval would produce meaningless results. This is not a spelling corrector or a query rewriter; it is a binary decision point with an optional clarification question for borderline cases. Place this prompt at the very start of your retrieval pipeline, after PII redaction but before any embedding or search call, to save compute and prevent bad answers.

The ideal deployment point is in a gateway or middleware layer that inspects every query before it reaches your retrieval infrastructure. You should use this prompt when your application accepts free-text input from end users, especially in customer-facing chat, search boxes, or API endpoints where input quality is unpredictable. It is also valuable when you pay per-embedding or per-search-operation and need to reject junk queries that would waste money. Do not use this prompt when you have already implemented client-side input validation that catches empty or min-length violations, or when your retrieval pipeline includes a robust fallback that gracefully handles near-empty result sets without cost penalties. It is also inappropriate for internal tooling where query authors are trusted and input quality is consistently high.

Before wiring this into production, define what 'malformed' means for your specific domain. A keyboard-mash string like 'asdfghjkl' is universally malformed, but a query like 'API' might be valid in a developer documentation RAG system while being too vague in a medical literature search. Calibrate your rejection threshold by running a representative sample of historical queries through the prompt and reviewing false positives—short-but-valid queries that were incorrectly rejected. If your application handles voice-to-text input, pair this prompt with a phonetic error correction step first, as ASR artifacts can mimic malformed input. After classification, log every rejection with the reason code and the original query (redacted of PII) to build a feedback loop for tuning the gatekeeper over time.

This template provides the core classification logic for a RAG gateway that must decide whether an incoming user query is worth processing. It is designed to be placed in your system instructions for a lightweight, fast classifier model—typically a smaller, cheaper model than your primary generation model. The prompt produces a structured JSON output with a classification label, a rejection reason when applicable, and an optional clarification question. You should adapt the [REJECTION_CATEGORIES], [MIN_QUERY_LENGTH], and [DOMAIN_GLOSSARY] placeholders to match your application's tolerance for noise and your knowledge domain's terminology.

textCopy
You are a query validation classifier for a retrieval system. Your job is to inspect user queries and decide whether they are well-formed enough to justify a retrieval operation.

## Classification Rules

Analyze the user query and classify it into exactly one of the following categories:

- **valid**: The query is a well-formed question or search string that can be answered with a retrieval step. Short queries like "pricing" or "returns" are valid if they contain real words and a discernible intent.
- **malformed**: The query contains keyboard mashing, random characters, copy-paste artifacts, or non-language input that cannot be interpreted as a search. Example: "asdfghjkl", "lorem ipsum dolor", "##$%^^&".
- **underspecified**: The query uses real words but lacks enough information to retrieve useful results. It is too vague, missing a subject, or relies entirely on pronouns without referents. Example: "tell me about it", "what about the other one", "help".
- **out_of_domain**: The query is well-formed but asks about topics outside the system's supported knowledge domain. Use the provided domain glossary to make this determination.

## Rejection Reasons

When classification is not "valid", provide a specific rejection reason from this list:

[REJECTION_CATEGORIES]

## Output Schema

Return a single JSON object with this exact structure:

{
  "classification": "valid" | "malformed" | "underspecified" | "out_of_domain",
  "rejection_reason": string | null,
  "clarification_question": string | null,
  "confidence": number  // 0.0 to 1.0
}

## Constraints

- Do not execute retrieval. Only classify.
- Do not answer the user's question.
- If classification is "valid", rejection_reason and clarification_question must be null.
- If classification is not "valid", rejection_reason must be populated.
- Generate a clarification_question only for "underspecified" queries. The question must be concise, non-leading, and ask for the specific missing information.
- Queries shorter than [MIN_QUERY_LENGTH] characters are not automatically malformed. Evaluate them on content.
- Treat domain-specific jargon, acronyms, and technical terms as valid language. Reference the provided domain glossary to avoid false positives.

## Domain Glossary

[DOMAIN_GLOSSARY]

## Examples

[EXAMPLES]

## User Query

[INPUT]

Adaptation guidance: Replace [REJECTION_CATEGORIES] with a concrete list of rejection reasons your application can act on programmatically—for example, gibberish_input, empty_after_cleaning, missing_subject, unsupported_domain. Set [MIN_QUERY_LENGTH] to an integer that reflects your application's tolerance; 2–3 characters is typical for catching empty or near-empty input without blocking valid short queries. Populate [DOMAIN_GLOSSARY] with a compact list of terms, acronyms, and proper nouns that are valid in your domain but might look like noise to a general-purpose model. Provide 4–8 [EXAMPLES] covering each classification category, including edge cases like short-but-valid queries and long-but-gibberish input. Wire the output into your gateway logic: if classification is not valid, return the rejection_reason and clarification_question to the caller without executing retrieval. Log every classification decision with the confidence score for later calibration and false-positive analysis.

The malformed query detection prompt should sit at the entry point of your retrieval pipeline, before any embedding computation or vector search. This position is critical because the entire purpose of this prompt is to prevent wasted compute on input that cannot produce meaningful results. In a typical RAG gateway, you would insert this prompt as a synchronous pre-check after basic input sanitization but before the query reaches your embedding model or search index. The prompt expects a raw user query string and returns a structured classification that your application code can act on without additional parsing ambiguity.

When wiring this prompt into your application, implement a strict validation layer around the model's output. The expected output schema is a JSON object with classification (one of valid, malformed, ambiguous), rejection_reason (a short string explaining why the query was rejected, or null for valid queries), and clarification_question (a suggested question to ask the user, or null). Your harness should validate that the model returned parseable JSON, that the classification field matches the allowed enum, and that rejection_reason is populated when classification is not valid. If the model output fails validation, implement a single retry with a stronger instruction to return valid JSON. If the retry also fails, log the raw output and treat the query as malformed with a generic rejection message to avoid passing unvalidated input downstream. For high-traffic systems, consider setting a latency budget of 500-800ms for this check and falling back to a heuristic keyword-based gibberish detector if the model call times out.

Model choice matters for this prompt. Smaller, faster models like Claude Haiku, GPT-4o-mini, or Gemini Flash are well-suited because the task is classification-focused and does not require deep reasoning. You can further reduce latency by using structured output modes or JSON mode if your provider supports it, which eliminates the need to parse markdown-wrapped JSON. Log every classification decision with the original query, the model's response, and the final routing action. This log becomes essential for tuning false-positive rates. Monitor two key metrics: the false-positive rate on short-but-valid queries like 'pricing' or 'API docs' and the false-negative rate on true gibberish like 'asdfghjkl;'. If false positives exceed 2-3% of traffic, add few-shot examples of short valid queries to the prompt. If false negatives appear, tighten the gibberish criteria. Always route rejected queries to a user-facing clarification flow rather than silently dropping them, and provide the clarification_question from the model output as a suggested prompt to the user.