Constraint Removal Ordering Prompt for Search Fallbacks

This prompt is designed for infrastructure teams building fallback retrieval paths in production RAG and search systems. Its job is to analyze an over-specified user query that has already returned zero results against your index. Instead of blindly dropping filters or rewriting the entire query, this prompt produces a scored, ordered relaxation plan. It ranks each constraint by semantic importance to the original intent, giving you a defensible removal order: drop this first, then this, then this. The output is not a new query but a strategic plan that your application code can execute step-by-step, stopping as soon as sufficient results are found.

Use this prompt when you have a structured or semi-structured query that failed due to over-specification—too many mandatory filters, tight numerical ranges, specific entity requirements, or combined temporal and categorical constraints. It assumes you already have a failed query representation (e.g., a JSON object with filters, terms, and ranges) and need to decide which constraint to relax first. The ideal user is a search engineer or RAG pipeline developer who controls the retrieval orchestration layer and can wire this prompt's output into a programmatic fallback loop. You should not use this prompt as a general query rewriter, for initial query formulation, or when the failure is due to index gaps rather than over-specification.

This prompt does not execute retrieval itself, nor does it generate the relaxed queries—it produces the ordering strategy. Your application harness must take the ranked removal plan and iteratively drop constraints, re-execute retrieval, and check result counts. The prompt also includes confidence scoring per constraint and intent drift checks, so you can set thresholds: if removing a constraint drops intent preservation below 0.7, stop and escalate rather than returning irrelevant results. Do not use this prompt when the query is already simple (one or two terms with no filters), when zero results are expected due to an empty corpus, or when you need a single rewritten query rather than a staged fallback plan.

This template generates a ranked relaxation plan from an over-specified query. It identifies which constraints to drop first based on semantic importance, producing an ordered sequence of broader queries. Each step includes a confidence score and an intent-drift check so your fallback logic can decide when to stop relaxing and when to escalate to a human or a different retrieval strategy.

textCopy
You are a search query relaxation specialist. Your job is to analyze an over-specified query that returned zero results and produce an ordered plan for removing constraints to broaden retrieval while preserving the original user intent.

## INPUT
Original Query: [ORIGINAL_QUERY]
Applied Filters: [APPLIED_FILTERS]
Corpus Description: [CORPUS_DESCRIPTION]
Domain Context: [DOMAIN_CONTEXT]

## TASK
1. Identify every constraint in the original query and applied filters. Constraints include entity names, temporal ranges, numerical thresholds, metadata facets, geographic limits, and required qualifiers.
2. For each constraint, assign a semantic importance score from 0.0 (decorative or incidental) to 1.0 (core to the intent).
3. Produce an ordered relaxation plan. The first step removes the least important constraint. Each subsequent step removes the next least important constraint from the remaining set.
4. For each relaxation step, generate the rewritten query and estimate the intent preservation score (0.0 to 1.0) after that constraint is removed.
5. Flag any step where the intent preservation score drops below [INTENT_FLOOR].

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "original_query": "string",
  "constraint_analysis": [
    {
      "constraint": "string",
      "type": "entity|temporal|numerical|metadata|geographic|qualifier",
      "importance_score": 0.0-1.0,
      "rationale": "string"
    }
  ],
  "relaxation_plan": [
    {
      "step": 1,
      "removed_constraint": "string",
      "rewritten_query": "string",
      "intent_preservation_score": 0.0-1.0,
      "below_intent_floor": true|false,
      "explanation": "string"
    }
  ],
  "recommended_stop_step": integer|null,
  "escalation_recommended": true|false
}

## CONSTRAINTS
- Do not remove more than one constraint per step.
- Never rewrite the query to change the core subject or action the user requested.
- If the original query has no removable constraints, return an empty relaxation plan and set escalation_recommended to true.
- If intent preservation drops below [INTENT_FLOOR] at any step, mark that step and recommend stopping at the previous step.
- Provide a concise rationale for every importance score and every rewrite.

Adaptation notes: Replace [ORIGINAL_QUERY] with the user's raw query string. [APPLIED_FILTERS] should include any structured filters already in use (date ranges, facets, source filters). [CORPUS_DESCRIPTION] helps the model understand what documents are available and why constraints might be too restrictive. [DOMAIN_CONTEXT] provides terminology and taxonomy hints. Set [INTENT_FLOOR] to your acceptable drift threshold—0.7 is a reasonable default for most applications, but raise it to 0.85 for regulated or high-precision domains. The output schema is designed for direct consumption by a fallback orchestrator: iterate through relaxation_plan steps, execute each rewritten_query, and stop when results are sufficient or when below_intent_floor is true.

This prompt is designed to sit inside a fallback retrieval controller, not as a standalone chat interaction. When the primary search returns zero or insufficient results, the controller calls this prompt with the original query and the applied filters. The model returns an ordered relaxation plan, and the controller executes each step until enough results are found or the plan is exhausted. The harness must enforce a stop condition: stop relaxing as soon as the result count exceeds a configured threshold, and never execute the full plan blindly.

The controller should parse the model's JSON output and validate it against a strict schema before acting on it. Each relaxation step must contain a constraint_to_remove, a removal_priority (integer rank), a confidence_score (0.0–1.0), and a relaxed_query_string. The harness should reject any step with confidence below 0.5 and either skip it or escalate for human review. Log every step—original query, relaxed variant, result count, and confidence—so the operations team can tune the threshold and detect intent drift over time.

For high-stakes domains (legal, healthcare, finance), add a human-in-the-loop gate before executing any relaxation step that drops a named entity, a temporal constraint, or a mandatory filter like jurisdiction or patient ID. The harness should pause, surface the proposed relaxation with the original query and confidence score, and wait for approval. For lower-risk applications, you can auto-execute steps above a higher confidence threshold (e.g., 0.85) but still log the decision for audit. Never relax a constraint that the system's access control layer enforces—those are non-negotiable and should be excluded from the prompt's input entirely.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 to maximize deterministic ordering. Implement a retry wrapper: if the model returns malformed JSON or a step with missing fields, retry once with the same input plus a validation error message. If it fails again, fall back to a simpler rule-based relaxation (e.g., drop the least frequent filter first) and alert the on-call channel. Wire the entire harness into your observability stack so you can track relaxation depth, confidence distributions, and result quality over time.