Shipped: answer-block diff view for reviewers

The answer-block diff view shipped this week.

Until now, when a drafted answer was regenerated — because the source block was edited, because the retrieval pipeline picked a different block on a re-run, or because a reviewer requested a new draft — the previous version of the answer was archived to history and the new version replaced it inline. Reviewers could see the current answer or pull up history. They could not see them side by side without manual diff work.

The diff view fixes that.

When an answer block is regenerated, the response now shows a small “diff” affordance at the top of the block. Click it, the response splits into two columns: the previous version on the left, the current version on the right. Word-level changes are highlighted: insertions in green, removals in red. The source block citation is shown for each version, with a clear visual cue if the regeneration also changed the source block (which is typical) or merely re-drafted from the same source (less common).

The lifecycle:

1. Initial draft. Block is generated, citation is attached. Standard behavior.
2. Regeneration. Source block is edited, OR retrieval picks a different block, OR a reviewer requests “redraft.” The new draft replaces the current view. The previous version is preserved.
3. Diff view. The reviewer hits the diff affordance and sees old vs. new with word-level highlighting and the source-block change called out.
4. Accept or revert. Two buttons under the diff. Accept commits the new version and archives the old. Revert restores the old version and archives the regeneration. Either action is logged.

Two notes worth calling out.

Diff is per-block, not per-section. A response section may contain ten answer blocks. Each diffs independently. A reviewer can accept seven and revert three without affecting the other blocks. The discipline is to keep the unit of review small enough that a reviewer makes considered decisions on each block, rather than a single thumbs-up on a wall of regenerated text.

Source-block changes are first-class. The most common reason for an answer-block regeneration is that the underlying KB source was updated — a new SOC 2 attestation, a refreshed pricing sheet, an updated security architecture diagram. The diff view explicitly shows that the source changed and links to the source-block diff alongside the answer diff. That makes it obvious whether the answer drift is because the source changed (correct, accept) or because the model paraphrased differently against the same source (inspect more carefully).

We expect this to be most useful in two contexts. First, gold-team review the day before submission, when source documents in the KB are still being updated and reviewers need to confirm that updates flowed through correctly. Second, post-mortem retrospection on lost bids, where the team is reading what the response actually said vs. what it would say today against the current KB.

The diff view lives in the Proposal Builder. It is on by default for all customer accounts.

A follow-up post on the engineering side of how we generate the diff at scale — particularly the part where the previous version’s verifier trace has to remain replayable even after the source block has changed — will land later in July.