Duplicate Resolution with Majority Vote Prompt

This prompt is designed for AI engineers and platform developers running ensemble or multi-model pipelines where conflicting duplicate entries appear across different model outputs. The core job-to-be-done is resolving disagreements about which records are duplicates and what the canonical value should be by using a majority vote across multiple model responses. You need this when a single deduplication pass produces unreliable results, when you are routing the same input to multiple models for redundancy, or when you are sampling multiple responses from a single model and need to reconcile conflicting duplicate/non-duplicate classifications. The ideal user is integrating this prompt into a production data pipeline, an agent loop, or a batch processing system where consistency and auditability matter more than raw speed.

Do not use this prompt when you have a single, high-confidence model output with a clear deduplication signal. In that case, a simpler exact or fuzzy deduplication prompt from this pillar is more appropriate and less expensive. This prompt is also a poor fit for real-time, low-latency user-facing features where running multiple models in parallel violates your latency budget. The majority vote mechanism assumes you have at least three independent outputs to compare; with only two, you cannot break ties without falling back to a configurable tie-breaking rule, which reduces the value of the voting approach. If your duplicates are always exact string matches, skip the voting overhead and use the Exact Duplicate Removal Prompt Template instead.

Before wiring this prompt into your application, ensure you have a clear definition of what constitutes a duplicate for your domain. The prompt requires you to supply a [DUPLICATE_DEFINITION] that tells the voting models how to compare records. Ambiguous definitions produce inconsistent votes and undermine the majority decision. You should also define your tie-breaking policy upfront—options include 'keep the most conservative result,' 'escalate for human review,' or 'use the highest-confidence model's vote.' After reading this section, proceed to the prompt template to see the exact input structure, then review the implementation harness for validation, logging, and model selection guidance.

This prompt template is designed for ensemble and multi-model pipelines where multiple outputs contain conflicting duplicate entries. Instead of manually reconciling differences, the prompt instructs the model to tally votes across outputs, apply tie-breaking rules, and produce a single resolved record set with full vote transparency. Use this when you have 3+ model outputs that may disagree on field values for the same logical record, and you need an auditable resolution path.

codeCopy
You are a duplicate resolution engine operating on [NUM_OUTPUTS] model outputs that may contain conflicting entries for the same logical records. Your task is to resolve duplicates using majority vote with configurable tie-breaking.

## INPUTS
- Model Outputs: [OUTPUTS_LIST]
- Record Identity Field: [IDENTITY_FIELD]
- Fields to Resolve: [FIELDS_TO_RESOLVE]
- Tie-Breaking Rule: [TIE_BREAKING_RULE]
- Confidence Threshold: [CONFIDENCE_THRESHOLD]

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "resolved_records": [
    {
      "[IDENTITY_FIELD]": "value",
      "resolved_fields": {
        "[field_name]": {
          "value": "resolved_value",
          "vote_tally": {
            "[value_option]": count,
            ...
          },
          "winning_criterion": "majority | tie_broken | below_threshold",
          "confidence": 0.0-1.0
        }
      },
      "source_output_ids": ["output_1", "output_2"],
      "resolution_status": "resolved | tied | below_threshold"
    }
  ],
  "unresolved_conflicts": [
    {
      "record_identity": "value",
      "field": "field_name",
      "vote_distribution": {},
      "reason": "no_majority | below_confidence | tie_not_broken"
    }
  ],
  "summary": {
    "total_input_records": N,
    "total_resolved_records": N,
    "total_unresolved_conflicts": N,
    "tie_breaks_applied": N,
    "below_threshold_flagged": N
  }
}

## VOTING RULES
1. Group outputs by [IDENTITY_FIELD] to identify duplicate candidates.
2. For each [FIELDS_TO_RESOLVE], tally values across all outputs containing that record.
3. If one value has >50% of votes, select it as the resolved value with winning_criterion "majority".
4. If no value has majority, apply [TIE_BREAKING_RULE]:
   - "keep_highest_confidence": Select the value from the output with highest model confidence score.
   - "keep_most_recent": Select the value from the most recent output timestamp.
   - "keep_longest": Select the longest non-null value.
   - "flag_for_review": Do not resolve; add to unresolved_conflicts.
   - "first_output_wins": Select the value from the first output in [OUTPUTS_LIST].
5. If the winning value's vote proportion is below [CONFIDENCE_THRESHOLD], set resolution_status to "below_threshold" and add to unresolved_conflicts.
6. Preserve all vote tallies for auditability.

## CONSTRAINTS
- Do not invent values not present in the input outputs.
- If a record appears in only one output, include it as resolved with vote_tally showing single-source.
- Handle null/missing field values by excluding them from vote tally.
- If [IDENTITY_FIELD] is missing for a record, flag it in unresolved_conflicts.
- Maintain the original output IDs for traceability.

To adapt this template, replace the square-bracket placeholders with your pipeline's specific configuration. [OUTPUTS_LIST] should be a structured array of model outputs with unique IDs and optional confidence scores. [IDENTITY_FIELD] is the field that determines whether two records refer to the same entity—choose a stable identifier like email, record_id, or a composite key. [TIE_BREAKING_RULE] must match one of the enumerated options; if your use case requires a custom rule, extend the list and document the behavior. For high-stakes pipelines, set [CONFIDENCE_THRESHOLD] to a conservative value like 0.8 and route below_threshold cases to a human review queue. Always validate the output JSON against the schema before ingesting resolved records into downstream systems.

The majority-vote deduplication prompt operates as a post-generation aggregator in an ensemble pipeline. It expects multiple model outputs—each containing a list of records, claims, or entities—and resolves conflicts by tallying votes across outputs. The prompt itself is stateless, so the application layer must collect all candidate outputs, normalize them into a consistent format, and inject them into the [CANDIDATE_OUTPUTS] placeholder. Each candidate should be labeled with a source identifier (e.g., model name, run ID, or timestamp) so the vote tally can attribute decisions. The prompt does not handle retrieval or tool calls; it is a pure reasoning step that consumes pre-generated outputs and emits a resolved canonical list with a vote breakdown.

Wire the prompt into a post-inference stage that fires after all ensemble models have returned. Validate each candidate output before feeding it into the deduplication step: reject malformed JSON, empty lists, or outputs that failed upstream schema validation. The harness should normalize field casing, trim whitespace, and optionally canonicalize values (e.g., date formats, identifier casing) before voting, because surface-form differences can split votes on semantically identical records. For confidence-weighted voting, attach a confidence field to each candidate record and include a [VOTING_MODE] parameter set to "weighted" in the prompt. The prompt template expects a [TIE_BREAKING_RULE] parameter—options include "keep_all", "drop_conflict", "prefer_source" with a specified [PREFERRED_SOURCE], or "human_review" which flags ties for manual resolution. Log every tie-breaking decision with the conflicting records, vote distribution, and chosen resolution for auditability.

Model choice matters: use a model with strong reasoning and structured output discipline for the aggregation step. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are suitable; avoid smaller or older models that may miscount votes or hallucinate canonical records. Set temperature=0 and enforce the output schema strictly—validate the resolved list against the expected schema before passing it downstream. If the output fails validation, retry once with the error message injected into the [CONSTRAINTS] field. For high-stakes pipelines (e.g., clinical data, financial records, legal claims), route all tie-broken or low-agreement records to a human review queue with the full vote tally and source attribution. Do not silently resolve conflicts when agreement falls below a configurable [MIN_AGREEMENT_THRESHOLD]. The prompt is not a substitute for upstream output quality—if ensemble models consistently produce conflicting garbage, fix the generation step before relying on majority vote to paper over systemic failures.