Role-Scoped Query Rewriting Prompt Template

This prompt rewrites a user's natural language query to incorporate their organizational role, department-specific terminology, and access boundaries before it hits a retrieval engine. The core job-to-be-done is ensuring that the same surface question—such as 'show me the latest product specs'—returns different documents for a sales engineer, a compliance officer, and a support agent, even when they query the same knowledge base. The ideal user is an enterprise RAG developer or search infrastructure engineer who already has a validated user role object and a defined permission model available at inference time. Without this role context, the prompt cannot perform its function, and you should not use it as a general-purpose query expander.

Use this prompt when you need to inject role-specific terminology (e.g., 'pricing sheet' vs. 'rate card'), scope constraints (e.g., 'only North America region docs'), and access boundaries (e.g., 'up to confidentiality level 3') into a query. It assumes the user's role and permissions are resolved upstream and passed in as structured input. If you need to extract permissions or access constraints directly from the user's natural language query, use the Permission-Aware Metadata Filter Generation Prompt. If your primary challenge is resolving anaphora or ellipsis across conversation turns, use the History-Conditioned Query Reformulation Prompt. This prompt is not a synonym expander, a session-context resolver, or a general query decomposition tool. It does one thing: scope a query to a role.

Before wiring this into production, confirm that your application layer can supply a validated role object with at least a role name, department, and access level. The prompt will fail silently or produce unhelpful rewrites if these fields are missing, stale, or incorrect. For high-stakes deployments—such as legal, financial, or healthcare retrieval—add a post-rewrite validation step that checks whether the rewritten query contains terms or scope constraints that exceed the user's documented permissions. A rewritten query that accidentally broadens access is a more dangerous failure mode than one that is overly restrictive. Start with a narrow set of roles and departments, evaluate the rewrite quality with role-specific test queries, and expand coverage only after you have evidence that the rewrites are both permission-safe and retrieval-effective.

This template provides a complete system and user message pair for role-scoped query rewriting. The system prompt establishes the rewriting policy, instructing the model to act as a retrieval pre-processor that injects role-appropriate terminology and enforces access boundaries. The user message supplies the raw query, the user's role profile, and the output schema. Replace every square-bracket placeholder with your application's runtime values before sending the request to the model.

textCopy
SYSTEM:
You are a retrieval query rewriter for an enterprise knowledge base with role-based access controls. Your job is to rewrite a user's raw query so that retrieval returns documents the user is authorized to see and that match their role-specific terminology.

Follow these rules:
1. Inject role-appropriate synonyms, acronyms, and domain terms from the user's [ROLE_TERMINOLOGY_MAP].
2. Add explicit scope constraints derived from the user's [ACCESS_BOUNDARIES] (e.g., department, project, clearance level).
3. Do not introduce terms that would expand the query beyond the user's authorized document scope.
4. Preserve the original query intent. Do not answer the query.
5. If the original query contains terms that conflict with the user's access boundaries, rewrite to the closest authorized equivalent or flag the conflict.
6. Output only the rewritten query string in the specified JSON format.

USER:
Raw Query: [USER_QUERY]
User Role: [USER_ROLE]
Department: [USER_DEPARTMENT]
Access Boundaries: [ACCESS_BOUNDARIES]
Role Terminology Map: [ROLE_TERMINOLOGY_MAP]

Output must be valid JSON matching this schema:
{
  "rewritten_query": "string",
  "injected_terms": ["string"],
  "scope_constraints_applied": ["string"],
  "conflicts_flagged": ["string"]
}

To adapt this template, start by defining your [ROLE_TERMINOLOGY_MAP] as a structured dictionary mapping user roles or departments to canonical terms, acronyms, and synonyms. The [ACCESS_BOUNDARIES] placeholder should receive a list of explicit scope constraints such as ["department:finance", "clearance:internal-only", "project:acme-q4"]. In production, these values should be assembled server-side from your identity and entitlements system—never accept them directly from the client. Before deploying, run the prompt against a golden dataset of role-query pairs and validate that injected_terms are role-appropriate and scope_constraints_applied match the user's actual permissions. If your application handles regulated data, add a human review step for any rewrite where conflicts_flagged is non-empty.

This prompt is not a standalone chatbot. It is a preprocessing step inside a retrieval pipeline. The application layer must supply the user's role, access scope, and query before calling the model, and it must validate the rewritten query before it touches any retrieval index. Treat the rewritten output as untrusted input to your search system—never pass it directly to a database or vector store without post-processing.

Integration pattern. Place this prompt between the user input handler and the retrieval orchestrator. The application should: (1) resolve the user's identity and fetch their role, group memberships, and permission boundaries from your identity provider or access control system; (2) assemble the prompt with [USER_QUERY], [USER_ROLE], [ACCESS_SCOPE], and [ORGANIZATION_TERMINOLOGY]; (3) call the model with temperature=0 and a low max_tokens ceiling (200–400 tokens is usually sufficient for a rewritten query string); (4) parse the output and validate that the rewritten query does not introduce terms or scopes outside the user's permission boundary; (5) log the original query, rewritten query, role, and validation result for audit; (6) pass only the validated rewritten query to your retrieval backend. For high-risk domains, insert a human approval step before retrieval when the rewrite introduces new scope constraints or when the validator flags a boundary violation.

Validation and guardrails. Implement a post-generation validator that checks: (a) the rewritten query does not contain permission escalation markers (e.g., terms like all, unrestricted, admin unless explicitly allowed by the user's role); (b) any injected metadata filters or scope constraints are a subset of the user's granted access; (c) the output is structurally a single query string, not an explanation or refusal. If validation fails, log the failure, fall back to the original user query with strict permission filters applied, and alert the operations team. For retrieval systems using structured filter clauses, parse the rewritten query to extract any filter directives and cross-reference them against the user's access control list before constructing the final search request.

Model choice and latency. This prompt is latency-sensitive because it sits on the critical path of every user search. Use a fast, instruction-tuned model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) rather than a large reasoning model. Cache frequent [ORGANIZATION_TERMINOLOGY] blocks per role to avoid redundant token processing. If your identity provider supports it, cache the assembled user profile context with a short TTL (e.g., 5 minutes) to reduce per-request assembly overhead. Monitor rewrite latency and set a timeout—if the model call exceeds 500ms, fall back to the original query with permission filters applied.

Observability and eval. Log every rewrite with the original query, rewritten query, user role, access scope, model version, and validation result. Use these logs to build a regression test suite: sample 100–200 real user queries across roles, manually verify that rewrites respect permission boundaries, and store them as golden test cases. Run this suite on every prompt or model change. Set up an eval that measures two failure modes: permission leakage (the rewrite introduces terms or scopes the user should not access) and over-restriction (the rewrite strips legitimate access). Both are production-regression signals that should block a deploy.