Domain Detection Prompt for Multi-Tenant Routing

This prompt is for AI platform engineers building multi-tenant systems where a single ingress point serves multiple customers, products, or business units. Before any tool is called or any policy is applied, the system must determine which tenant domain the user's request belongs to. A wrong domain assignment means the wrong tools, the wrong data access policies, and the wrong response contract are used. This playbook provides a prompt that produces a domain label, a subdomain classification, and an out-of-scope flag, with explicit checks for cross-tenant leakage and boundary enforcement.

Use this prompt when your system's available tools, data stores, and response policies are gated by tenant identity and that identity must be inferred from the user's natural language input rather than an explicit tenant selector or API key claim. This is common in AI-powered support platforms, internal copilots spanning multiple business units, and SaaS products where a single assistant interface serves distinct customer accounts. The prompt is designed to be placed at the ingress layer, before any tool dispatch, retrieval, or agentic reasoning occurs. It must return a structured, machine-readable output that downstream middleware can act on deterministically. Do not use this prompt when tenant context is already available from a trusted source of truth, such as a validated JWT claim, a session-bound tenant ID, or a URL path parameter. Adding an inference step where a deterministic lookup already exists introduces unnecessary latency, cost, and a new failure mode with no compensating benefit.

The primary risk this prompt mitigates is cross-tenant leakage: a request from Tenant A being processed with Tenant B's tools, data, or policies. The secondary risk is boundary violation, where a request outside any supported domain is processed as if it were in-scope, producing a hallucinated or inappropriate response. Before deploying this prompt, ensure you have defined a closed, exhaustive domain taxonomy, a clear out-of-scope policy, and a deterministic fallback path for low-confidence or out-of-scope classifications. The prompt is a classification gate, not a conversational interface. It should fail closed.

The following prompt template is designed to be dropped directly into your AI application's system instructions or as a user message payload. It forces the model to reason about domain boundaries before routing, which is critical in multi-tenant systems where a wrong domain assignment exposes tools, data, or policies from another tenant. Replace every square-bracket placeholder with your specific taxonomy, policies, and input data before deployment.

textCopy
You are a domain detection classifier for a multi-tenant AI platform. Your job is to analyze the user's request and determine which tenant domain it belongs to, or if it falls outside all supported domains.

## TAXONOMY
[DOMAIN_TAXONOMY]

## INPUT
[USER_INPUT]

## INSTRUCTIONS
1. Analyze the input against the taxonomy above.
2. If the input clearly maps to a single domain, return that domain.
3. If the input maps to multiple domains, return the most specific match.
4. If the input does not map to any domain, set `in_scope` to false.
5. Do not guess. If the domain is ambiguous, set `confidence` below 0.8 and flag for review.

## OUTPUT_SCHEMA
Return ONLY a valid JSON object with this exact structure:
{
  "domain": "string (from taxonomy or 'unknown')",
  "subdomain": "string or null",
  "confidence": 0.0-1.0,
  "in_scope": true/false,
  "reasoning": "brief explanation of the classification decision"
}

## CONSTRAINTS
- Never return a domain not listed in the taxonomy.
- If confidence is below [CONFIDENCE_THRESHOLD], set `in_scope` to false and `domain` to 'unknown'.
- Do not include any text outside the JSON object.

To adapt this template for your system, start by replacing [DOMAIN_TAXONOMY] with your actual list of supported domains and subdomains. Use a structured format like domain: subdomain1, subdomain2 or a JSON object that the model can parse. Replace [USER_INPUT] with the variable that holds the incoming user message in your application code. Set [CONFIDENCE_THRESHOLD] to a value between 0.7 and 0.9 depending on your risk tolerance—lower thresholds reduce false out-of-scope flags but increase cross-tenant leakage risk. If your platform uses tool dispatch based on domain, consider adding a [TOOLS] section that lists available tools per domain, but keep it out of this classifier to maintain separation of concerns. The classifier should only determine domain; a downstream router should map domain to tools.

Before shipping this prompt, build a validation harness that parses the JSON output and checks that the domain field matches an entry in your taxonomy exactly. Log every classification where confidence is below your threshold or where in_scope is false. These logs become your primary observability signal for taxonomy gaps and domain boundary drift. Run this prompt against a golden dataset of known inputs per domain and measure cross-tenant misclassification rate—any non-zero rate on known inputs is a blocking bug, not a tuning exercise.

The domain detection prompt is designed to sit at the ingress layer of a multi-tenant AI platform, before any tenant-specific tools, policies, or context are loaded. In a typical implementation, an API gateway or middleware function receives an unstructured user input, calls the LLM with this prompt, parses the structured output, and uses the domain_label to fetch the appropriate tenant configuration. The out_of_scope flag acts as a circuit breaker: if true, the request is rejected or routed to a generic fallback handler without ever touching tenant-specific logic. This prevents cross-tenant leakage and ensures that a request misclassified as legal never reaches a healthcare tenant's PHI-handling tools.

Wire the prompt into your application with a strict validation layer. The model must return valid JSON matching the output schema; if parsing fails, retry once with a repair prompt that includes the raw output and the schema. After parsing, validate that domain_label exists in your active tenant registry and that subdomain is a recognized value for that domain. If confidence is below your configured threshold (start with 0.85 and tune based on production traffic), route to a human review queue or a clarification prompt rather than proceeding with low-confidence routing. Log every classification decision with the input hash, domain label, confidence, and routing target for auditability and drift monitoring. For high-throughput systems, consider caching classification results keyed by a normalized input hash to avoid redundant LLM calls for identical or near-identical inputs.

Model choice matters here. Use a fast, cost-efficient model for this classification task—GPT-4o-mini, Claude Haiku, or a fine-tuned small model are appropriate. The prompt is designed for zero-shot use, but if you observe consistent misclassification for specific domains, add few-shot examples to the [EXAMPLES] placeholder rather than rewriting the instructions. Do not inject tenant-specific context or tool definitions before classification; that creates a circular dependency where you need the domain to load the context but you need the context to detect the domain. The only exception is a global allow-list of supported domains and subdomains, which should be injected into the [CONTEXT] placeholder at runtime. Finally, set up eval checks that specifically test for cross-tenant leakage: feed inputs that sound like one domain but should route to another, and verify the classifier respects domain boundaries rather than overfitting to surface vocabulary.