Account Merge Conflict Routing Prompt

This prompt is designed for data platform engineers and migration specialists who need to resolve duplicate account records during consolidation, merger, or data cleanup projects. The core job is to evaluate multiple conflicting account profiles for a single real-world customer and produce a single canonical record selection with a clear, auditable rationale. It is not a generic deduplication script or a fuzzy matching tool; it assumes that a conflict has already been detected and that the model is being asked to adjudicate which record should survive based on provided evidence.

Use this prompt when you have a bounded set of candidate accounts (typically 2–5) and rich metadata to compare, such as creation timestamps, last activity dates, associated billing IDs, verified email domains, or linked contracts. The prompt is most effective when the conflict is complex enough that a simple rule like 'keep the oldest record' would be incorrect. It is explicitly designed for high-stakes routing decisions where data loss—such as discarding active entitlements, payment methods, or support history—has real business consequences. Do not use this prompt for real-time request routing or for bulk deduplication of millions of records without human review gates.

The ideal reader is an engineer integrating this prompt into a migration pipeline, an admin tool, or an internal operations console. You should have access to structured account objects, not just free-text notes. The prompt expects you to provide a conflict summary and the candidate records as input. It returns a structured decision with a selected_account_id, a confidence_score, a rationale summary, and a data_loss_risk flag. Before deploying, you must wire the output to a human review queue for any decision where confidence_score is below your threshold or data_loss_risk is true. Never allow fully automated merge execution without this gate.

This prompt template is designed to be copied directly into your application code, test harness, or prompt management system. It accepts a set of conflicting account records and a merge context, then returns a structured decision identifying the canonical account, the records to deprecate, and the evidence chain supporting the resolution. Every placeholder is enclosed in square brackets so you can safely perform string replacement before model invocation without accidentally colliding with model-native tokenization.

textCopy
You are an account merge conflict resolver for a data platform. Your job is to analyze conflicting account records that may represent the same customer and produce a canonical merge decision.

## INPUT
[INPUT]

## CONTEXT
[MERGE_CONTEXT]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a single JSON object with the following structure. Do not include commentary outside the JSON.
{
  "canonical_account_id": "string",
  "deprecated_account_ids": ["string"],
  "confidence": "high|medium|low",
  "rationale": "string explaining the decision with specific field-level evidence",
  "data_loss_risks": ["string describing any fields or history that may be lost"],
  "manual_review_required": true|false,
  "manual_review_reason": "string or null"
}

## RULES
1. Prefer the account with the most complete profile data, longest verified activity history, and strongest identity signals.
2. If two accounts have conflicting verified identity fields (e.g., different government IDs), flag for manual review.
3. If any account has active subscriptions, contracts, or billing relationships, preserve that account as canonical unless identity evidence strongly contradicts it.
4. If confidence is "low" or data loss risks include regulated data, set manual_review_required to true.
5. Never merge accounts where the identity mismatch suggests fraud or account takeover. Flag those for manual review with the reason "potential fraud indicators."
6. If [RISK_LEVEL] is "high", require manual review regardless of confidence.

## EXAMPLES
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with the appropriate content for your system. [INPUT] should contain the serialized account records in your preferred format (JSON lines, structured JSON array, or a normalized table representation). [MERGE_CONTEXT] should describe the trigger for the merge review—such as a customer support ticket, an automated duplicate detection flag, or a data migration batch identifier. [CONSTRAINTS] should encode your organization's specific merge policies, such as regulatory data residency rules, retention requirements, or tier-preservation mandates. [EXAMPLES] should include one or two few-shot demonstrations of correct merge decisions, including edge cases like identity mismatches and partial profile overlaps. [RISK_LEVEL] is a runtime parameter your application should set based on the data sensitivity of the accounts involved—use "high" when regulated personal data, financial records, or healthcare information is present. After generating the output, validate the JSON structure, confirm that canonical_account_id is not also present in deprecated_account_ids, and log the decision with the model's raw response for auditability.

The Account Merge Conflict Routing Prompt is designed to sit inside a data migration or account consolidation pipeline, not as a standalone chatbot. It should be invoked programmatically when your system detects duplicate account records for the same customer. The prompt expects a structured input payload containing candidate accounts, match evidence, and business rules. The output is a canonical account selection with a conflict resolution rationale. This prompt is not a replacement for deterministic matching logic; it is the conflict resolver that runs after your identity resolution engine has flagged a hard case that cannot be resolved by rule-based matching alone.

Wire the prompt into your application as a gated step in the merge pipeline. Before calling the model, assemble the [INPUT] payload with: a list of candidate account records (each with ID, creation date, last activity, tier, and associated contacts), the [MATCH_EVIDENCE] that triggered the duplicate detection (email, phone, external ID overlaps), and the [BUSINESS_RULES] that govern merge precedence (e.g., 'prefer the oldest account,' 'retain the highest tier,' 'preserve the account with recent billing activity'). Validate the input payload against a schema before sending it to the model. If required fields are missing, abort and route to a human review queue with a clear explanation of what data is absent. After receiving the model response, validate the output against the [OUTPUT_SCHEMA]: it must contain a selected_account_id, a merge_direction (e.g., 'merge B into A'), a rationale array of reasons, and a risk_flags array. If the output fails schema validation, retry once with the same input and an added [CONSTRAINTS] note about the validation failure. If the second attempt also fails, escalate to a human operator with both attempts logged.

For high-risk merges—such as those involving accounts with billing history, regulatory data, or large transaction volumes—add a mandatory human approval gate after the model returns a result. Do not execute the merge automatically. Instead, present the model's recommendation alongside the candidate accounts in a review UI, and require an authorized operator to confirm or override the selection. Log every merge decision, including the model's rationale, the operator's action, and a timestamp, for auditability. This prompt is best used with models that have strong structured output support (GPT-4o, Claude 3.5 Sonnet) and low temperature settings (0.0–0.1) to maximize deterministic behavior. Avoid using this prompt with small or instruction-untuned models that may hallucinate account IDs or produce malformed JSON under conflict conditions.

Common failure modes to monitor in production: the model selecting an account that was already marked as deleted or merged in a prior run (validate account status before and after the call), the model producing a rationale that contradicts the business rules you provided (log and flag for review), and the model failing to detect a hard split where no single canonical account is appropriate (watch for low-confidence outputs or risk flags that indicate the merge should not proceed). Instrument the harness to track merge resolution latency, schema validation pass rates, retry rates, and human override frequency. If the human override rate exceeds 20%, revisit your business rules and prompt instructions—the model may not be receiving clear enough guidance to make decisions that align with operational expectations.