Merging Conflicting Chunks Before the Fold

Treat each retrieved chunk as a set of typed fields before you treat it as prose. You do not need a perfect parser; you need a small, auditable extractor per field type, and you need to compare only chunks that are about the same thing.

Start with an entity key. Two chunks both mentioning a dosage are not in conflict if one is about adults and one about children. Build the key from the query plus the entities the chunks share, then compare only within a key group.

Two rules make this usable in practice. First, normalize before you compare: parse "March 3" and "3 March" to the same date object, and strip currency symbols into an explicit unit. Second, treat missing fields as unknown, not zero. A chunk that omits a date is not in conflict with a dated chunk; it is simply undated, which matters for the precedence step. The provenance discipline described in practical retrieval write-ups is the right mental model here: for every claim you should be able to say which source supports it, where exactly in the source, and whether it was quoted, summarized or inferred (provenance checks for RAG).

A useful detection order, cheapest first:

1. Compare numeric fields and dates. These are deterministic and catch most operational conflicts.
2. Compare entity identifiers. Two different account numbers for the same customer name is a hard conflict.
3. Compare policy clauses by normalized form, then by condition and exception.
4. Only if the first three pass, check free-text claims for entailment contradiction, and treat a low-confidence contradiction as advisory rather than decisive.

Worked example. A support query asks for the return window for a specific product. Chunk A says 30 days from delivery. Chunk B says 14 days from purchase. The numeric field differs (30 versus 14, outside a zero tolerance), and the date basis differs (delivery versus purchase), so the pair is flagged on two fields. Had both said 14 days and differed only on the basis, the pair would still be flagged, because the basis changes the deadline for a slow shipment. That is the sort of clause-level difference that a keyword search would miss entirely.

Once a pair is flagged, the resolution must be mechanical. A model reasoning about credibility mid-generation will drift across runs; a fixed rule will not. Use this order and stop at the first criterion that separates the chunks:

1. Authoritative source. A designated primary source wins over a secondary one. The policy document beats a support email; the contract beats a wiki summary. Authority is a property you assign per collection in metadata, not a judgment the model makes.
2. Explicit timestamp. An explicitly dated chunk wins over an undated one, and the later date wins when both are dated and both are authoritative at the same level. Prefer the date the source states about itself over thecrawl date, and record both.
3. Specificity. The chunk that names the condition and the exception wins over the one that states the rule alone. "Returns accepted within 30 days, except for perishable goods" beats "Returns accepted within 30 days" when the query concerns perishable goods.
4. Else escalate. If the chunks tie on all three, the rule cannot decide. Stop and route to a human.

That order is not arbitrary. Source authority is the strongest signal you can encode cheaply, and timestamps come second because a dated revocation of an undated policy is usually the truthful reading. Specificity comes third because a more specific rule is normally the operative exception, and because preferring specificity keeps exceptions from being flattened by a general clause. Escalation is the honest default; a system that always produces an answer will occasionally produce a confident wrong one, and that failure is expensive.

The empirical support for telling the model what kind of conflict it faces is relevant here too. Google's work showed measurable gains from explicit conflict-category information rather than leaving the model to infer credibility from surface text (the conflict taxonomy study). Your rule engine produces exactly that category, so pass it downstream instead of discarding it.

A caution on the timestamp rule: it must be applied to the value the source is about, not to the document's age. A price sheet from a later date that lists an older effective period is not more current on the question of which price applies during that period. Store the effective date separately from the publication date, and prefer effective date when both chunks carry one.

Two artifacts leave the merge step: a merged context for the model, and a conflict record for humans and for later retrieval.

The merged context should be minimal and structured. Hand the model the resolved value, one supporting snippet per field, the conflict category, and an instruction to state the basis of the answer. A layered prompt that separates task, source boundary, evidence rules, conflict handling, missing information, citations and stop conditions is more reliable than an open-ended "use the context" instruction (RAG prompting guide). Keep retrieved text framed as evidence, never as instruction authority, since retrieved chunks can carry injected instructions.

The conflict record is the durable part, and it should contain:

{
  "conflict_id": "cf_88213",
  "entity_key": "product:PB-441 return-window",
  "detected_fields": ["quantity", "date_basis"],
  "chunks": [
    {"chunk_id": "c_1021", "source_tier": "primary",
     "effective_date": "2024-11-01", "verbatim": "Returns accepted within 30 days of delivery."},
    {"chunk_id": "c_2388", "source_tier": "secondary",
     "effective_date": null, "verbatim": "Returns accepted within 14 days of purchase."}
  ],
  "rule_applied": ["authoritative_source"],
  "winner": "c_1021",
  "loser_retained": true,
  "reviewer": null,
  "reviewer_decision": null,
  "status": "auto_resolved"
}

Three properties matter. The chunks are stored verbatim, in line with the finding that verbatim units retrieve and reason better than extracted summaries (the memory representation ablation). The rule that fired is stored by name, not by narrative. And the reviewer fields exist even when empty, so escalation writes into the same schema.

Record retention is not optional paperwork. Compaction and summarization erode exact wording: one study of long-running agent memory found production compaction preserving 53% of safety rules after one round and 10% after five, naming the effect the Compaction Cliff (Compaction Cliff). If the counterfactual chunk lives only inside a summary, the reviewer cannot check it later. Store the record outside the working context, in the pattern operating-system-style memory management calls archival storage, which is paged back in only when needed (MemGPT).

Escalation fails when the reviewer receives two paragraphs and no framing. Design the review surface around the conflict record.

The reviewer sees, in order: the query, the two (or more) conflicting values side by side, the field or clause that differs, the rule engine's verdict and why it declined, and any prior decisions on the same entity key. Their job is a single choice among a small set: accept the winner, accept both with a condition, accept neither because both are wrong, or request a fresher source. Each choice writes back to the record with an identifier and a timestamp.

A worked example with numbers shows why this matters. Suppose a pricing query returns chunk A at 42.00 per seat from the primary price sheet effective in March, and chunk B at 37.50 per seat from a secondary partner deck with no date. The value differs by 4.50, about 12%, well outside a 1% tolerance, so it is flagged. The authoritative-source rule picks A. The model answers 42.00 and cites the price sheet. The partner deck is retained in the conflict record, and if a reviewer later marks B as an approved partner discount, the record shows the correction and the next retrieval on that key can surface both with the condition attached. Without the record, the same disagreement reappears next week with no memory of how it was settled, which is the failure mode that episodic memory designs exist to prevent (semantic vs episodic vs procedural memory).

Reviewer load is the practical constraint. Instrument escalation rate per entity key and per field type. A key that escalates repeatedly usually needs a source-authority fix, not more reviewers: either the secondary source should be demoted in metadata or the primary source should be refreshed. Treat repeat escalations as a data governance signal.

For summaries that mention resolved conflicts, prefer extractive phrasing. Guidance on production summarization distinguishes extractive from abstractive approaches and notes that abstractive paraphrase carries higher hallucination risk, which is why legal and compliance text is usually summarized extractively (production summarization systems). A merger that must mention a conflict should quote the clause that lost, not describe it.

You cannot validate conflict handling on queries that never conflict. Build a small adversarial set, and score the pipeline on behaviors rather than prose quality.

Score four rates: false positives (harmless pairs flagged), misses (real conflicts passing through), correct rule attribution, and time to reviewer decision. Then, for the answer layer, track citation fidelity separately, since a valid citation that does not contain the asserted fact is a distinct failure from a wrong citation (summarization troubleshooting). A compact evaluator harness that runs these cases on every pipeline change is cheap compared with the cost of one confidently wrong policy answer.

If you want a single API to reach several models while you compare merge and answer behavior across them, that is one of the things Quanta Inference is for (https://quantaintelligence.ai/inference). For teams that would rather hand the whole retrieval-and-merge pipeline to specialists who return a working implementation, Quanta experts take the brief and deliver it (https://quantaintelligence.ai/agents).