Conflict Resolution Prompt for Extracted Fields

This prompt is designed for data quality engineers and pipeline operators who have run multiple extraction passes or used multiple extractors on the same source document and now face contradictory field values. The core job-to-be-done is not simple extraction, but reconciliation: surfacing every conflict, applying resolution rules, adjusting confidence scores, and producing a single resolved record with a full audit trail. The ideal user is someone who owns a data ingestion pipeline where downstream consumers—analytics databases, operational systems, compliance archives—cannot tolerate unresolved conflicts or silently dropped values. Required context includes the original source text, the conflicting extracted values for each field, any field-level confidence scores, and a defined set of resolution rules or priorities.

Use this prompt when you have multiple extraction sources per field and need programmatic evidence of why one value was chosen over another. It is appropriate for high-stakes pipelines where conflict annotation is cheaper than downstream data corruption: financial filings, contract metadata, clinical data, regulatory submissions, and any workflow where an auditor might ask 'why was this value selected?' The prompt expects structured input—typically a JSON object mapping field names to arrays of candidate values with their sources and confidence scores—and produces a resolved record alongside a conflict log. You should also use it when your extraction architecture includes multiple models, multiple prompt variants, or human-in-the-loop extractions that can disagree.

Do not use this prompt when you have only one extraction source per field, as there is nothing to reconcile. It is also the wrong tool when the cost of conflict annotation exceeds the value of resolution—for example, in low-stakes classification where picking the highest-confidence value silently is acceptable. Avoid this prompt when your resolution rules are so complex or domain-specific that they require deterministic code rather than LLM reasoning; the model can apply rules you provide, but it should not invent financial reconciliation logic or legal precedence rules. Finally, do not use this prompt when the conflicting values represent genuinely ambiguous ground truth that should be preserved as multiple valid interpretations rather than collapsed into a single record. In that case, use the Ambiguity Flagging During Record Assembly prompt instead, and route the record for human review.

This template is designed to be dropped directly into your AI harness as a system or user message. It expects you to supply the conflicting extractions, the target output schema, and your resolution rules. The prompt instructs the model to produce a single resolved record, annotate every conflict it resolved, explain its rationale, and adjust confidence scores downward where ambiguity remains. Do not use this prompt when you need a simple majority-vote merge without audit trails—this prompt is for auditable, explainable conflict resolution.

textCopy
You are a data quality engineer reconciling contradictory field extractions from a single source document. Your job is to produce one resolved record, not to choose sides silently.

## INPUTS
- Extracted Fields: [EXTRACTED_FIELDS]
- Target Schema: [OUTPUT_SCHEMA]
- Resolution Rules: [RESOLUTION_RULES]
- Domain Context: [DOMAIN_CONTEXT]

## INSTRUCTIONS
1. For each field in the target schema, examine all conflicting extracted values provided in [EXTRACTED_FIELDS].
2. Apply the resolution rules in [RESOLUTION_RULES] to select or synthesize the best value. Rules may include:
   - Prefer the value with the highest confidence score.
   - Prefer the value extracted from the most specific span.
   - Prefer the value that is consistent with other resolved fields.
   - Prefer the value that matches a canonical form or authority list.
   - If no rule resolves the conflict, preserve the ambiguity.
3. For every conflict you resolve, add an entry to the `conflicts` array containing:
   - `field`: the field name.
   - `candidates`: the conflicting values and their sources.
   - `resolved_value`: the value you selected or synthesized.
   - `rationale`: a concise explanation of why you chose this value.
   - `rule_applied`: which resolution rule you used.
4. If a conflict cannot be resolved with high confidence, set `resolved_value` to the best candidate but mark `confidence` as `low` and add an `ambiguity_note` explaining what remains uncertain.
5. Adjust the `confidence` score for each resolved field. If resolution required choosing between equally plausible candidates, reduce confidence. If one candidate was clearly superior, confidence may remain high.
6. Do not invent values. Every resolved value must be traceable to at least one extracted candidate.
7. If a required field has no extracted candidates, set it to `null` and add a `missing_field` entry with `reason`: "no_extraction_available".

## OUTPUT FORMAT
Return a single JSON object matching this structure:
{
  "resolved_record": { ... },
  "conflicts": [
    {
      "field": "string",
      "candidates": [
        {
          "value": "...",
          "source_span": "...",
          "confidence": 0.0
        }
      ],
      "resolved_value": "...",
      "rationale": "string",
      "rule_applied": "string",
      "confidence": 0.0,
      "ambiguity_note": "string or null"
    }
  ],
  "missing_fields": [
    {
      "field": "string",
      "reason": "string"
    }
  ],
  "resolution_summary": {
    "total_fields": 0,
    "conflicts_resolved": 0,
    "conflicts_ambiguous": 0,
    "fields_missing": 0,
    "overall_confidence": 0.0
  }
}

## CONSTRAINTS
- Do not discard conflicting values. Every candidate must appear in the `conflicts` array.
- Do not merge values unless a resolution rule explicitly permits synthesis.
- Preserve source spans for every candidate.
- If [DOMAIN_CONTEXT] includes regulatory or safety requirements, prioritize conservative resolution and flag any value that could be misinterpreted.

Before wiring this into production, test it against a golden set of known conflicts where you already know the correct resolution. Measure whether the model applies your resolution rules consistently and whether it correctly flags ambiguous cases instead of guessing. If your domain is regulated, add a human review step for any record where conflicts_ambiguous is greater than zero or overall_confidence falls below your threshold. The next section covers how to build that validation harness.

The Conflict Resolution Prompt for Extracted Fields is not a standalone utility—it is a pipeline stage that sits between raw field extraction and record assembly. In a production system, you will typically call this prompt after multiple extraction passes or models have produced contradictory values for the same field within a single document. The prompt expects a structured input containing the conflicting extractions, their source spans, confidence scores, and any extraction metadata. You should wrap this prompt in an application harness that validates inputs before sending them, parses the resolved output against a known schema, and routes ambiguous resolutions to a human review queue when the model's own confidence falls below your operational threshold.

The harness should enforce a strict input contract. Before calling the model, validate that each conflicting field entry includes: the field name, the list of contradictory values, each value's source span (character offsets or paragraph references), and per-extraction confidence scores. If any required field is missing, reject the input early rather than sending incomplete data to the model. On the output side, parse the resolved record against a schema that requires resolved_value, resolution_rationale, conflict_annotation (a structured object describing what was dropped and why), and adjusted_confidence. If the model returns a confidence below your configured threshold—typically 0.7 for high-stakes pipelines—route the record to a human review queue with the original conflicting extractions and the model's rationale attached. Log every resolution decision, including cases where the model chose to preserve ambiguity rather than force a resolution, as these are critical signals for improving extraction quality upstream.

For model choice, prefer a model with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all perform well on this task when given explicit output schemas. Use response_format with a JSON schema if your provider supports it; otherwise, include the schema inline in the prompt and validate the output with a JSON Schema validator before accepting it. Implement a retry loop with a maximum of two retries for malformed outputs. On the first retry, include the validation error message in the retry prompt. On the second failure, log the failure, preserve the original conflicting extractions, and escalate to human review. Do not silently drop records that fail resolution—missing data is often worse than ambiguous data in downstream systems.

This prompt works best when integrated into a broader extraction pipeline that already produces per-field confidence scores and source spans. If your upstream extraction step does not provide these, you will need to add a pre-processing stage that annotates extractions with span references and confidence estimates before conflict resolution can run. Avoid using this prompt as a substitute for improving extraction quality at the source. If you find that more than 20% of records trigger the conflict resolution stage, investigate whether your extraction prompts, models, or document preprocessing need improvement. The conflict resolver is a safety net, not a primary extraction strategy.