Role-to-Filter Mapping Prompt for Hybrid Search

This prompt is designed for search infrastructure teams building hybrid retrieval systems where different user roles must see different subsets of documents. It maps a user's role and organizational attributes to a set of pre-defined metadata filters, then merges those filters with any query-derived constraints to produce a complete filter object ready for execution against vector and keyword indexes. Use this prompt when your search index contains documents tagged with access control metadata such as department, clearance level, region, or project codes, and you need a deterministic, auditable mapping from user identity to retrieval scope.

This prompt belongs in the query preprocessing stage of a RAG pipeline, after authentication and before retrieval execution. It assumes you already have a defined role-to-filter mapping table and a user profile service that provides role attributes at query time. The prompt does not perform authentication, does not decide what a user's role should be, and does not evaluate whether the role-to-filter mapping table is correct. Those responsibilities belong to your identity provider, access control system, and policy administration layer respectively. The prompt's sole job is to apply a known mapping consistently and produce a structured filter object that your search backend can consume without further interpretation.

Do not use this prompt when access control rules are dynamic, context-dependent, or require real-time policy evaluation that exceeds what a static mapping table can express. If your system needs attribute-based access control with complex boolean logic, time-bound permissions, or document-level security labels that change during a session, implement those checks in your application layer rather than in a prompt. Similarly, avoid this prompt when the role-to-filter mapping is trivial enough to hardcode in application logic—adding an LLM call for a simple department filter lookup adds latency and cost without benefit. For high-security environments where filter correctness must be formally verified, run this prompt's output through a deterministic validator that rejects any filter clause not present in the canonical mapping table before the query reaches your search index.

This template is designed to be pasted into your system prompt or query preprocessing step. It instructs the model to act as a search filter compiler, translating a user's role profile and a natural language query into a structured, machine-readable filter object. The primary job is to enforce access control and scope at the retrieval layer, ensuring that a user's role never sees documents outside their permission boundary, while also applying any explicit constraints mentioned in the query itself. Use this when you have a defined role-to-filter mapping table and need a deterministic, auditable translation layer before executing a hybrid search.

textCopy
You are a search filter compiler for a hybrid retrieval system. Your task is to map a user's role and organizational attributes to a set of pre-defined metadata filters, then merge those filters with any query-derived constraints to produce a complete, structured filter object.

INPUT:
- User Role Profile: [USER_ROLE_PROFILE]
- User Query: [USER_QUERY]
- Role-to-Filter Mapping Table: [ROLE_FILTER_MAP]

INSTRUCTIONS:
1. Identify the user's primary role and any secondary attributes (e.g., department, region, clearance level) from the [USER_ROLE_PROFILE].
2. Look up the corresponding metadata filters in the [ROLE_FILTER_MAP]. These are mandatory and must always be applied.
3. Analyze the [USER_QUERY] for any explicit filter constraints (e.g., date ranges, document types, specific sources).
4. Merge the role-based filters and query-derived filters into a single, non-contradictory filter object. If a query-derived constraint is more restrictive than a role-based one, the more restrictive constraint wins. If a query requests a scope outside the role's permission, ignore the query's request and log a warning.
5. Output the final filter object in the exact [OUTPUT_SCHEMA] format.

CONSTRAINTS:
- Never generate a filter that is less restrictive than the user's role-based permissions.
- If the role-to-filter mapping is missing for a given attribute, default to the most restrictive filter for that user's department.
- If the query is ambiguous about a filter, do not guess; omit the optional filter and note the ambiguity.

OUTPUT_SCHEMA:
{
  "filters": {
    "mandatory": [
      {"field": "string", "operator": "eq|ne|in|gte|lte|range", "value": "any"}
    ],
    "optional": [
      {"field": "string", "operator": "eq|ne|in|gte|lte|range", "value": "any"}
    ]
  },
  "warnings": ["string"],
  "applied_role": "string"
}

To adapt this template, replace the square-bracket placeholders with data from your application's user profile service and role management system. The [ROLE_FILTER_MAP] should be a serialized JSON or YAML object that explicitly defines which metadata fields and values each role is permitted to see. For example, a 'Sales' role might map to {"department": "sales", "region": "us-east"}. The [USER_QUERY] is the raw string from the user. Before deploying, validate the output against your actual search index schema to ensure field names and operators match. For high-stakes access control, always log the warnings field and consider a human review step if a warning indicates a potential permission conflict or an over-constrained query that might return zero results.

This prompt is not a standalone chatbot interaction; it is a deterministic component inside a hybrid search request pipeline. The application layer must supply the user's role, organizational attributes, and the query-derived constraints before calling the model. The model's output—a structured filter object—must be validated, merged with existing query constraints, and attached to the vector or keyword search request. Treat the model as a translator that converts role context into machine-readable filter clauses, not as a decision engine that can override security policy.

Pipeline integration: Place this prompt after query parsing and before search execution. The application should call the model with the user's role profile and the parsed query constraints, then take the returned filter object and merge it with any query-derived filters using a deterministic merge strategy (e.g., AND for security boundaries, configurable OR/AND for preference filters). The merged filter object is then passed to the search backend. Validation: Before the filter reaches the search index, validate that (1) all required access-control fields are present, (2) no filter clause expands beyond the user's documented permissions, and (3) the filter does not over-constrain to the point of guaranteed zero results (e.g., contradictory date ranges or mutually exclusive facets). If validation fails, log the failure, fall back to a safe minimal filter (user's base access scope only), and alert the search operations channel.

Retry and fallback: If the model returns malformed JSON, missing required fields, or filters that fail validation, retry once with a stricter prompt variant that includes the validation error message and requests a corrected output. If the retry also fails, use the user's static permission filter from the identity system as a safe fallback and log the full failure context for debugging. Observability: Log the user role, input constraints, model-generated filter, merged filter, validation result, and search latency at each step. Attach a trace ID that follows the request from query intake through filter generation to search execution. This trace data is essential for debugging role-to-filter mapping errors, detecting permission boundary violations, and measuring the prompt's impact on recall and precision. Model choice: Use a fast, instruction-following model (e.g., GPT-4o-mini, Claude Haiku) for this task; the output is structured and the latency budget is tight because this step sits on the critical path of every search request.

What to avoid: Do not use the model's output directly without validation. Do not allow the model to generate filter clauses for security boundaries that the application should enforce deterministically (e.g., tenant isolation, document classification levels). The model should map roles to pre-defined filter templates, not invent new access control rules. If your permission system is complex or high-stakes, keep the model's role scoped to preference and relevance filters, and enforce access control in the search backend or a post-retrieval authorization layer. For regulated environments, require human review of the filter mapping logic during initial deployment and after any role definition changes.