Keep the source turn range alongside each conversation summary, and store those turns separately from the history presented to the model. If a summary omits a constraint, you need the original messages to reconstruct it.

Suppose a user says, “Deploy to staging. Production needs approval.” After summarization, the model only receives, “The user wants a deployment.” The next response suggests a production command. If the summary is the only remaining record, you cannot recover the missing restriction.

Record what the summary covers

Treat each conversation summary as derived state, not as the authoritative record. The retained messages are the source of truth, and the summary is a compact representation that can be discarded and regenerated when it becomes inaccurate. Rebuilding may produce different wording, so the replacement still needs validation.

An application-owned summary record might look like this after a repair:

{
  "conversationId": "chat-42",
  "sourceHistoryRevision": 18,
  "firstTurn": 1,
  "lastTurn": 12,
  "summaryRevision": 4,
  "summarizerVersion": "deployment-summary-v2",
  "text": "The user requested a staging deployment. Production requires approval."
}

Here, turn numbers are stable sequence numbers within a single conversation, and both endpoints are inclusive. A turn consists of the user message and the assistant and tool messages that follow, up to the next user message. Close the range only after all related exchanges complete. Do not use positions in a mutable message list as source identifiers.

sourceHistoryRevision identifies the persisted history snapshot used for generation. summaryRevision identifies a replacement of this summary. Keep the configured prompt and model settings used for summarizerVersion available for investigation. These are application-specific fields, not part of a reducer API contract.

A revision number alone does not preserve old messages. If turns can be edited, retain immutable message versions or a reconstructable historical snapshot. An immutable snapshot ID can identify the source, while a source-range hash can detect changes but cannot restore the original messages.

The model can receive the summary for turns 1 through 12, plus the original messages from turn 13 onward. Removing older messages from the request does not require deleting them from storage. See Controlling Token Growth with Chat Reducers for details on reduction setup.

Rebuild from the source turns

When you find a faulty summary:

  1. Mark it invalid so new requests do not use it. Pause affected requests or use retained history within the request’s token budget while the repair is in progress.
  2. Load the recorded range from the retained source snapshot or immutable turn records. If the original versions or required messages are unavailable, report that the summary cannot be completely rebuilt.
  3. Generate a replacement from those messages. Check the specific failed constraint before accepting it. In this example, the replacement must preserve staging as the target and include the production approval requirement. Simply retrying the same prompt may repeat the omission.
  4. Save the replacement with a new summary revision. Use a conditional write that checks the expected summary revision and ensures the covered source turns remain unchanged. The conversation revision tip explains the conditional-write pattern.

For append-only history, adding turns 13 through 20 does not invalidate a repair covering turns 1 through 12. Check the covered range’s version or hash at publication, rather than rejecting every append just because the entire conversation revision has advanced.

If later summaries relied on the faulty summary, invalidate and rebuild those as well. Record the IDs and revisions of input summaries so you can locate those dependents. Feeding the faulty text back into the summarizer can perpetuate its omission.

When to use this

Use this when summaries carry context across a long-running conversation and losing an earlier fact might change later answers. Add the failed conversation as a regression case for the summarizer. Production authorization must still come from application policy.

Short, disposable chats may not need stored summaries. The ability to rebuild also depends on your retention policy because expired or deleted source messages are no longer available for recovery. Apply deletion and redaction rules to derived summaries as well.

Sources