Combined AND/OR Filter Logic Prompt Template

This prompt is designed for platform engineers and search relevance teams who need to convert complex natural language queries into structured boolean filter logic. When a user types 'documents about compliance from the legal or finance team published after January but not about GDPR,' the retrieval system needs a nested AND/OR/NOT filter structure that respects operator precedence and resolves conflicts between constraints. This prompt handles multi-facet queries where simple flat filters fail.

Use this prompt when your search interface must support compound constraints across date ranges, categorical facets, source filters, and exclusion patterns simultaneously. The ideal deployment context is an enterprise search or RAG system where users express multi-dimensional information needs in a single query. Required context includes a defined metadata schema with known field names, types, and valid values. Without this schema, the model cannot reliably map user terms to filter clauses. You should also have a clear operator precedence policy—whether AND binds tighter than OR, or vice versa—and a conflict resolution strategy for contradictory constraints like 'from marketing and from legal.'

Do not use this prompt for single-facet extraction or simple equality filters. If a user query only contains one type of constraint, such as a date range or a single source filter, a dedicated extraction prompt like the Date Range Extraction Prompt Template or Source Filter Generation Prompt Template will be simpler, cheaper, and more reliable. This prompt is also not appropriate when your search backend does not support nested boolean logic, or when latency budgets are too tight for an additional LLM call in the retrieval path. In those cases, consider pre-computed filter templates or rule-based extraction.

Before deploying this prompt, verify that your evaluation dataset includes queries with mixed AND/OR/NOT constraints, ambiguous operator scoping, and contradictory conditions. These edge cases are where flat filter extraction fails and nested boolean logic becomes necessary. If your production queries rarely combine multiple facet types, you may be over-engineering the filter layer. Start with single-facet extraction prompts and only introduce this combined logic prompt when user behavior data shows compound queries are common and retrieval quality degrades without them.

This template is designed for production search and RAG systems where users express complex filter logic in natural language—combining categories, date ranges, source restrictions, and numerical thresholds with explicit AND, OR, and NOT relationships. The prompt instructs the model to produce a structured boolean tree rather than a flat list of filters, preserving operator precedence and nesting that downstream search backends require. Use this when your application must handle queries like 'documents about pricing from the sales or marketing team, but not from Q3, and only for enterprise accounts.'

textCopy
You are a search filter translator. Given a user's natural language query, extract all filter constraints and produce a nested boolean filter structure that preserves the logical relationships between constraints.

[INPUT]

[CONTEXT]
- Available metadata fields: [AVAILABLE_FIELDS]
- Field types and valid values: [FIELD_SCHEMA]
- Current date for relative time resolution: [ANCHOR_DATE]
- User's access scope (if applicable): [USER_SCOPE]

[OUTPUT_SCHEMA]
Return a JSON object with this structure:
{
  "original_query": "string",
  "filter_tree": {
    "operator": "AND" | "OR" | "NOT",
    "operands": [
      {
        "type": "constraint" | "subtree",
        "field": "string (for constraint type)",
        "operator": "eq" | "neq" | "gt" | "gte" | "lt" | "lte" | "in" | "not_in" | "between" | "contains",
        "value": "string | number | array | {min, max}",
        "confidence": 0.0-1.0
      },
      {
        "type": "subtree",
        "operator": "AND" | "OR" | "NOT",
        "operands": [...]
      }
    ]
  },
  "unresolved_terms": ["terms that couldn't be mapped to fields"],
  "warnings": ["operator precedence notes", "potential contradictions"]
}

[CONSTRAINTS]
1. Preserve explicit AND/OR/NOT relationships from the user's language.
2. When operator precedence is ambiguous, default to AND binding tighter than OR, and note this in warnings.
3. Map all date expressions to ISO 8601 ranges using [ANCHOR_DATE].
4. Only use fields present in [AVAILABLE_FIELDS]. Place unmapped constraints in unresolved_terms.
5. Flag detected contradictions in warnings (e.g., 'before 2020 AND after 2023').
6. Assign confidence scores: 1.0 for explicit constraints, lower for inferred or ambiguous ones.
7. For NOT constraints, ensure the scope of negation is clear in the tree structure.
8. Do not invent fields, values, or operators not supported by [FIELD_SCHEMA].

[EXAMPLES]
Query: "Reports about cloud costs from engineering or finance, but not drafts"
Output:
{
  "original_query": "Reports about cloud costs from engineering or finance, but not drafts",
  "filter_tree": {
    "operator": "AND",
    "operands": [
      {
        "type": "constraint",
        "field": "topic",
        "operator": "contains",
        "value": "cloud costs",
        "confidence": 0.9
      },
      {
        "type": "subtree",
        "operator": "OR",
        "operands": [
          {"type": "constraint", "field": "department", "operator": "eq", "value": "engineering", "confidence": 1.0},
          {"type": "constraint", "field": "department", "operator": "eq", "value": "finance", "confidence": 1.0}
        ]
      },
      {
        "type": "subtree",
        "operator": "NOT",
        "operands": [
          {"type": "constraint", "field": "status", "operator": "eq", "value": "draft", "confidence": 1.0}
        ]
      }
    ]
  },
  "unresolved_terms": [],
  "warnings": []
}

Query: "Enterprise deals over 100k from last quarter, excluding the APAC region"
Output:
{
  "original_query": "Enterprise deals over 100k from last quarter, excluding the APAC region",
  "filter_tree": {
    "operator": "AND",
    "operands": [
      {"type": "constraint", "field": "segment", "operator": "eq", "value": "enterprise", "confidence": 1.0},
      {"type": "constraint", "field": "deal_value", "operator": "gt", "value": 100000, "confidence": 1.0},
      {"type": "constraint", "field": "close_date", "operator": "between", "value": {"min": "2024-10-01", "max": "2024-12-31"}, "confidence": 0.95},
      {
        "type": "subtree",
        "operator": "NOT",
        "operands": [
          {"type": "constraint", "field": "region", "operator": "eq", "value": "APAC", "confidence": 1.0}
        ]
      }
    ]
  },
  "unresolved_terms": [],
  "warnings": ["'last quarter' resolved relative to anchor date 2025-01-15"]
}

Adapt this template by replacing the square-bracket placeholders with your application's runtime values. [AVAILABLE_FIELDS] should list every filterable metadata field in your search index. [FIELD_SCHEMA] must specify each field's data type and valid values—this prevents the model from hallucinating operators or values your backend cannot process. [ANCHOR_DATE] is critical for temporal queries; pass the current date in ISO format so relative expressions resolve consistently. [USER_SCOPE] is optional but recommended for enterprise deployments where access controls should constrain filter generation. The [EXAMPLES] section is deliberately included in the prompt to demonstrate the expected tree structure and confidence annotation pattern. Replace these with examples from your own domain for better in-domain accuracy.

Before deploying, validate that your application layer can consume the nested filter_tree structure. Most search backends require flattening or recursive traversal of boolean trees. Build a post-processing step that converts the tree into your backend's query DSL—whether Elasticsearch bool queries, Pinecone metadata filters, or PostgreSQL WHERE clauses. Add a validation check that rejects filter trees referencing unknown fields or unsupported operators before they reach your search index. For high-stakes search experiences, log unresolved_terms and warnings so your team can monitor extraction quality and expand field coverage over time.

The combined AND/OR filter prompt is not a standalone component. It sits between the user's natural language query and your search backend's structured filter API. In a typical RAG or hybrid search pipeline, the user query first hits this prompt to produce a structured filter object, which is then merged with the vector or keyword query before execution. The harness must validate the output against your backend's filter schema before any search runs—an invalid filter clause can silently return zero results or, worse, a full-table scan. Treat this prompt's output as untrusted user input until it passes schema validation, operator whitelisting, and field existence checks.

Start by defining a strict output schema for the filter object. The prompt should return a JSON structure with explicit AND, OR, and NOT grouping, where each leaf node contains a field, operator, and value. Your harness must validate this structure before forwarding it to Elasticsearch, OpenSearch, Pinecone, PostgreSQL, or any custom search API. Implement a validation layer that checks: (1) all field names exist in your search schema, (2) operators are from an allowed list (eq, neq, gt, gte, lt, lte, in, contains, exists), (3) value types match the field's expected type, (4) no contradictory clauses exist (e.g., x > 10 AND x < 5), and (5) nesting depth does not exceed your backend's limit. If validation fails, log the raw prompt output, the validation error, and the original user query for debugging. Do not silently fall back to an unfiltered search—instead, return a controlled error or strip the invalid clause and flag the response with reduced confidence.

For retry logic, implement a single retry with a reformulated prompt that includes the validation error message. The retry prompt should say: 'The previous filter output failed validation with error: [VALIDATION_ERROR]. Original query: [USER_QUERY]. Please correct the filter structure and return only valid JSON.' If the retry also fails, escalate to a human review queue or fall back to a safe default filter (e.g., last 30 days for temporal queries, or no filter with a warning). Log every retry attempt, the validation errors, and the final resolution path. For high-stakes enterprise search where missing documents has compliance implications, require human approval on any filter that modifies access scope or includes exclusion clauses before execution. Model choice matters here: use a model with strong JSON mode and instruction-following for the initial extraction, but consider a smaller, faster model for the retry if latency is critical. Never pass raw LLM output directly to your search backend without this harness layer.