Domain Overlap Conflict Resolution Prompt

This prompt is designed for a specific, high-stakes job: resolving a routing conflict after a domain classifier has already identified two or more legitimate candidate domains for a single input. It is not a domain classifier itself. Use it when an input legitimately spans multiple domains with conflicting handling requirements—for example, a customer support ticket that is both a billing dispute and a technical outage report, or a healthcare query that involves both clinical advice and legal liability. The core job-to-be-done is to produce a single, auditable routing decision by applying explicit precedence rules, risk signals, and policy requirements to break the tie. Wrong-domain routing in these scenarios carries compliance risk, data isolation requirements, or SLA implications that make a naive guess unacceptable.

The ideal user is an AI platform engineer or technical decision-maker building a multi-tenant, multi-product, or multi-department routing system. You should have already implemented a domain classification step that returns a list of candidate domains with confidence scores. This prompt is the next stage in the pipeline, consuming that list and the original input to output a final, reasoned routing decision. Do not use this prompt for initial domain discovery, for inputs that clearly fall into a single domain, or for low-stakes routing where a simple confidence threshold is sufficient. Using it for simple classification adds unnecessary latency, cost, and complexity. It is a tie-breaker, not a classifier.

Before implementing this prompt, ensure you have a defined taxonomy of domains, a written precedence policy (e.g., 'legal concerns always take priority over general inquiries'), and a clear understanding of the compliance and SLA risks for each domain. The prompt's value is in enforcing these human-defined rules consistently. The next step after reading this playbook is to adapt the prompt template with your specific domain taxonomy and precedence rules, then build a test harness with overlapping domain pairs to validate that the resolution logic matches your policy before deploying it to production.

This template is designed to be pasted directly into your system prompt or user message. It forces the model to resolve domain overlap conflicts by applying explicit precedence rules before any downstream processing occurs. The prompt requires the model to identify all candidate domains, detect conflicts in handling requirements, apply a defined precedence policy, and produce a structured resolution record. This is not a classification prompt—it assumes domain candidates have already been identified and focuses solely on conflict resolution.

codeCopy
You are a domain conflict resolution engine. Your job is to resolve conflicts when an input legitimately spans multiple domains with incompatible handling requirements.

## INPUT
[INPUT]

## CANDIDATE DOMAINS
[CANDIDATE_DOMAINS]

## DOMAIN HANDLING REQUIREMENTS
[DOMAIN_HANDLING_REQUIREMENTS]

## PRECEDENCE RULES
Apply these rules in order. The first rule that resolves the conflict wins.
[PRECEDENCE_RULES]

## RISK SIGNALS TO WEIGH
[RISK_SIGNALS]

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "primary_domain": "string",
  "conflicting_domains": ["string"],
  "conflict_type": "string",
  "precedence_rule_applied": "string",
  "resolution_rationale": "string",
  "risk_signals_present": ["string"],
  "overridden_requirements": ["string"],
  "requires_human_review": boolean,
  "audit_trail": {
    "rule_evaluation_order": ["string"],
    "rule_outcomes": [{"rule": "string", "matched": boolean, "reasoning": "string"}]
  }
}

## CONSTRAINTS
[CONSTRAINTS]

## RESOLUTION INSTRUCTIONS
1. Identify all handling requirement conflicts between candidate domains.
2. Evaluate each precedence rule in order against the identified conflicts.
3. Apply the first matching rule to select the primary domain.
4. Document which requirements are being overridden and why.
5. Flag for human review if any risk signal threshold is met or if no rule resolves the conflict cleanly.
6. Produce the audit trail showing every rule evaluated and its outcome.

To adapt this template, replace each placeholder with your specific data. [CANDIDATE_DOMAINS] should list the domains already identified by your upstream classifier, not raw input. [DOMAIN_HANDLING_REQUIREMENTS] must include the specific handling rules, policies, or constraints that differ between domains—this is what creates the conflict. [PRECEDENCE_RULES] is the most critical section: define explicit, ordered rules such as 'Safety domain always takes precedence over all others' or 'If PII is present, route to the compliance domain regardless of other signals.' [RISK_SIGNALS] should enumerate triggers that force human review, such as 'legal content detected,' 'financial transaction implied,' or 'multiple high-severity domains in conflict.' [CONSTRAINTS] can include output format requirements, latency budgets, or domain-specific policies. Test this prompt with cases where domains have genuinely incompatible requirements—if your domains never conflict, you do not need this prompt.

Before deploying, validate the output against the schema programmatically. The audit_trail.rule_evaluation_order must list every rule from your precedence rules in the exact order they were evaluated. The requires_human_review flag must be true whenever a risk signal is present or when no precedence rule cleanly resolves the conflict. Build an eval set with known conflict cases where the correct primary domain is unambiguous, and measure whether the model consistently applies your precedence rules rather than inventing its own resolution logic. For high-stakes domains like legal, healthcare, or finance, always route requires_human_review: true outputs to a review queue and log the full audit trail for compliance. The most common failure mode is the model skipping the precedence rules and resolving conflicts based on its own judgment—your eval set must catch this explicitly.

This prompt is designed to sit between a domain classifier and a downstream dispatcher in your routing pipeline. When the upstream classifier detects that an input spans multiple domains with conflicting handling requirements, this prompt resolves which domain takes priority. The output is a structured decision with an audit trail, not just a label. You should invoke this prompt only when a conflict is detected—running it on every input wastes latency and cost. The typical trigger is a multi-label classification result where the top two or more domain scores exceed a configurable threshold (e.g., 0.4 confidence each) and the domains have known policy conflicts in your routing table.

Wire the prompt into your application with a pre-invocation guard that checks for actual domain conflicts before calling the model. Maintain a conflict map in your application config—a JSON or database table listing domain pairs that require resolution and their precedence rules. For example, {"conflict_pairs": [{"domains": ["legal", "general_support"], "default_priority": "legal", "requires_human_review": true}]}. When the classifier returns overlapping domains, check this map. If no conflict exists, route to the highest-confidence domain directly. If a conflict exists, populate the prompt's [DOMAIN_A], [DOMAIN_B], [INPUT], and [PRECEDENCE_RULES] placeholders from your conflict map and the original user input. The [RISK_SIGNALS] placeholder should be populated by a separate risk classifier or keyword detector that flags PII, regulatory terms, security language, or escalation indicators in the input.

Output validation is critical because a malformed resolution can silently route sensitive data to the wrong queue. Parse the model's JSON response and validate: (1) the selected_domain field matches one of the input domains, (2) the confidence field is a float between 0.0 and 1.0, (3) the reasoning field is a non-empty string, and (4) the audit_trail object contains conflict_detected, precedence_applied, and overridden_signals fields. If validation fails, retry once with the same prompt plus the validation error message appended as a [PREVIOUS_ERROR] context. If the retry also fails, route to a human review queue with the raw classifier output, conflict map entry, and failed resolution attempts attached. Never silently fall through to a default domain when conflict resolution fails—this is how compliance incidents happen.

Model choice matters. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models for this task because the reasoning requires weighing multiple policy signals and producing consistent audit trails. Set temperature=0 to maximize deterministic behavior—conflict resolution should not be creative. Enable structured output mode if your provider supports it, binding the response to a schema that matches your expected output fields. Log every resolution to your observability platform: input hash, domains in conflict, selected domain, confidence, reasoning, and whether the resolution was automated or escalated to human review. This audit log is your defense when someone asks why a legal question landed in the general support queue.

Testing this harness requires a golden dataset of inputs known to span conflicting domains. For each test case, define the expected selected_domain and minimum acceptable confidence. Run the full pipeline—classifier, conflict detection, resolution prompt, validation, and routing—and measure end-to-end accuracy. Pay special attention to false-negative conflicts: inputs that should have triggered resolution but didn't because the upstream classifier missed the secondary domain. These are more dangerous than false positives because they bypass your conflict resolution entirely. Add these missed cases to your classifier's training or few-shot examples. Finally, set up a periodic review of escalated cases to identify patterns where your conflict map needs updating—new product launches, policy changes, or regulatory shifts can create domain overlaps your map doesn't cover yet.