Disagreement and adoption

A panel that always agrees tells you nothing you couldn’t have got from one model. The interesting exchanges are the ones where the providers don’t agree — and for those, “here is a synthesized answer” is not enough. You want to know which claim was contested, who was on each side, what each of them actually said, and whether you’d rather have one of their answers than the synthesis.

This article covers that path end to end. For how Polycode decides that a claim was contested in the first place, see fan-out and consensus; for the rest of the trace, see the inspector.

Splits show up under the answer

A finished answer carries a Split on row beneath its Sources row: one chip per contested claim, each labelled with the claim itself and carrying a small glyph per provider on each side. Claims that only one side spoke to get a Solo run after them.

Clicking a Split on chip opens that claim’s card in the inspector. Clicking a Solo chip goes to the cited provider’s trace card instead — the same jump a Sources pill makes. Past four split chips the row folds to three plus a +N more chip, which opens the full section.

The row is only there when there’s something to show. A finalized answer whose every sentence was uncontested has no row, and neither does an answer you’ve replaced by adopting a peer’s reply — see below.

Where the panel split

The inspector grows a Where the panel split section between the consensus overview card and the per-provider trace. One card per contested claim, in the order the claims appear in the answer; the first is expanded and the rest are collapsed.

Each card shows:

• The claim, as the answer states it, citation chips intact.
• The sides — a card header carries one provider glyph per side member, sides separated by a middle dot, so you can see the shape of the disagreement before expanding anything.
• Each side’s providers as pills, labelled with the provider and the model, because two models on one provider are two different voices.
• Each provider’s closest passage from its own full response.

The section closes with a line worth taking literally: “Sides are citation clusters, not a judgment of who is right.” Polycode is telling you where the panel diverged. It is not scoring the arguments.

Closest passages, and what they are not

Under each provider on a side, Polycode shows the passage from that provider’s full response that most closely matches the claim, labelled <model> · closest passage.

That match is lexical. It looks for the provider’s own wording nearest to the claim’s wording; it does not understand either. Most of the time that lands on exactly the sentence you wanted. Sometimes nothing in a provider’s response is close enough to be worth showing, and rather than offer you a weak match Polycode shows an Open trace link instead — go read the whole reply.

This is the honest version of a hard problem. A semantic match would be better and is not what’s implemented, so the label says which one you’re looking at.

Per-peer actions

Hover a finished provider trace card — or give it keyboard focus — and three actions appear. The same three appear on each side of a split card.

They’re revealed rather than always-on because a trace card is a dense thing already, and because these are per-provider actions — showing three of them on every card at rest would treble the visual weight of a panel you mostly read.

Diff vs answer

Diff vs answer opens a two-pane sheet: the provider’s full response on the left, the synthesized answer on the right, aligned sentence by sentence. Sentences only one side has are tinted; sentences both share are not.

The footer says “Sentence alignment · lexical, not semantic”, and that is the same caveat as the closest-passage match: the alignment pairs sentences by their words. A provider that made the same point in different words will show as two unmatched sentences rather than one shared one. Read the tinting as “these sentences are literally different”, not “these ideas are different”.

Each pane names its own side by provider and model, so a comparison between two models on one provider — two OpenRouter routes, say — doesn’t render as “OpenRouter” twice.

The sheet also carries Use <model>’s answer, which does the same thing as the action row’s Use as answer and then closes the sheet.

Use as answer

Adopting a provider’s response makes it the answer you see in the conversation. It is a display choice, and it is reversible.

What changes:

• The provider’s glyph replaces the Polycode brand mark. The mark means “this text was synthesized”, and adopted text was not.
• A provenance row appears: an Answer from <Provider> · <model> chip, a note recording that you replaced the synthesized answer and when, and Restore synthesized answer.
• The Split on row hides. The split analysis describes the synthesized answer, and that is no longer what’s on screen.
• Markdown export emits the displayed answer with an attribution line, so an exported conversation doesn’t silently credit Polycode’s synthesis for a provider’s words.

What does not change:

• The synthesized answer is kept. Adoption is an overlay, never a destructive edit — Restore brings the synthesis back whenever you want it.
• The Consensus of row and the trace. The panel still ran, every provider still has its card, and the receipts are untouched.
• The recorded spend. You already paid for the fan-out and the synthesis pass; choosing which text to display doesn’t refund or re-bill anything.

Regenerating the exchange clears the adoption — a regenerate produces a new synthesis, and an adoption of the old round would have nothing to overlay.

What’s next

• Fan-out and consensus — how a claim gets classified as uncontested, split, or solo in the first place.
• The inspector — the rest of the trace: per-provider cost, latency, tokens, roles, and debate rounds.
• Modes — set a provider’s role to Critic, or turn on a debate round, to change how much the panel argues before it answers.