Conversation Forking and Branching Prompt Template

This prompt template is for engineering teams building chat UIs that let users edit a prior message and regenerate the response from that point. The core challenge is assembling a model request that preserves the conversation trunk (messages before the edit) while correctly representing the branch (the edited message and any subsequent turns). Without a structured assembly pattern, the model receives contradictory context, loses track of which messages belong to which branch, or hallucinates a merged history that never happened. The template provides a deterministic method for identifying the edit point, isolating the trunk, and constructing a clean branch so the model can generate a coherent continuation without being confused by the original, now-superseded messages.

Use this template when your product supports message editing, version history, or A/B-style conversation exploration where a user can modify a prior turn and request a new response from that point forward. It is particularly valuable in copilot and assistant interfaces where users refine instructions, correct misunderstandings, or explore alternative paths without starting a new session. The template includes branch identification logic (which message was edited), trunk preservation rules (all messages before the edit point), and branch assembly instructions (the edited message plus any regenerated turns). It also defines merge-conflict detection signals for cases where the user edits a message that already has downstream responses, helping the system decide whether to discard, archive, or flag the orphaned branch.

Do not use this template for simple append-only chat where no message is ever edited after it is sent. In those systems, the conversation history is a linear sequence and standard multi-turn context packing is sufficient. Similarly, avoid this pattern when your product handles edits by simply replacing the message in-place and re-sending the entire history without branch awareness—that approach works for short, informal chats but breaks down when the model needs to understand which version of the history is canonical. If your system archives old branches for audit or user review, pair this prompt with a branch storage strategy that preserves the original messages outside the active model context. For high-stakes applications where an incorrect branch merge could cause confusion or harm, add a human review step before the regenerated response is shown to the user.

This template assembles a prompt that enables a chat model to understand it is operating on a branch of a prior conversation. The user has edited a previous message, and the model must regenerate from that point while retaining the full history before the edit. The template uses a system message to establish branch awareness, then injects the trunk messages (the unedited history up to the edit point), a branch marker, the edited message, and any subsequent branch-specific turns. This structure prevents the model from confusing the original timeline with the new branch and supports merge-conflict detection when the branch is later reconciled.

textCopy
SYSTEM:
You are operating in a conversation branching mode. The conversation below contains a trunk history followed by a branch marker and an edited message. The trunk represents the original conversation up to the point where the user edited message [EDIT_INDEX]. The branch begins at the marker and contains the edited version of that message plus any new turns that follow. Treat the trunk as immutable context. Generate your response based on the branch, not the original message that was edited. If the user asks about the edit, acknowledge the change without referencing the original message content unless explicitly instructed. Do not merge timelines.

TRUNK:
[TRUNK_MESSAGES]

--- BRANCH POINT (message [EDIT_INDEX] edited) ---

BRANCH:
[EDITED_MESSAGE]
[BRANCH_TURNS]

To adapt this template, replace [TRUNK_MESSAGES] with the full conversation history up to but not including the edited message, formatted as alternating USER: and ASSISTANT: turns. Replace [EDIT_INDEX] with the zero-based index of the edited message in the original conversation. Replace [EDITED_MESSAGE] with the user's new version of that message, prefixed with USER (edited):. Replace [BRANCH_TURNS] with any assistant or user turns that have already occurred on this branch, if the regeneration is not the first branch turn. If the branch is fresh, this field can be empty. Always validate that [TRUNK_MESSAGES] does not include the original unedited message at [EDIT_INDEX]—including it creates a timeline conflict that degrades model behavior. For high-stakes applications such as legal or clinical review, log the assembled prompt with a branch identifier and require human review of the edit before regeneration.

This prompt is not a standalone request. It must be embedded in an application harness that manages a conversation tree data structure, where each node represents a user or assistant message with a unique identifier and a parent pointer. The harness tracks the current 'trunk' path and any 'branch' paths created when a user edits a prior message. Before calling the model, the harness assembles the prompt by walking the tree from the root to the current branch tip, collecting messages in chronological order, and injecting branch metadata—including the edit point identifier, the original message that was replaced, and the new user message—into the prompt template's placeholders.

The assembly layer must enforce several constraints before inference. First, validate that the edit point [EDIT_NODE_ID] exists in the tree and is not the root or the latest assistant message. Second, check that the branch depth does not exceed a configurable limit (e.g., 3 nested forks) to prevent combinatorial explosion. Third, compute the total token count of the assembled context and truncate the trunk history before the edit point if necessary, using a sliding window that preserves at least the last N messages prior to the fork. Fourth, assign a deterministic [BRANCH_ID] (e.g., a short hash of the edit point and new user input) and log it alongside the model request for traceability. On the model response, the harness must store the assistant message as a child of the new user message in the branch, not on the trunk, and update the UI to show the branch as the active path. If the user later accepts the branch, the harness can promote it to the new trunk and archive the old trunk path.

For production deployment, instrument the assembly layer with structured logs that capture the branch ID, edit point, trunk length, branch length, token count, and model latency. Implement a retry policy for malformed outputs: if the model fails to return a valid response or produces a merge conflict marker without a resolvable diff, retry once with a simplified prompt that omits the merge-conflict detection instruction and forces a clean branch continuation. Add an eval harness that tests the assembly logic against known conversation trees, verifying that the correct messages are included, the branch identifier is consistent, and the model does not leak trunk-only information into the branch response. Finally, expose a human-in-the-loop review step when the model flags a merge conflict, allowing a user to manually resolve the conflict before the branch is committed to the conversation state.