Source-linked AI summary
Mutable Transcripts: Mitigating Context Pollution through Editable Conversation State
Dan Barry, Andrew Hines
TL;DR
Immutable chat histories can retain outdated context as user intent changes. Mutable transcripts let users revise the full conversation through natural-language requests, and a prototype study and transcript analysis report improved interaction quality and less obsolete retained context. The paper presents this as early feasibility evidence, while noting that full-transcript rewriting adds computational overhead.
Problem
Immutable chat histories can retain outdated or irrelevant information that continues to influence responses after user intent changes.
Source: §1.2 · p. 2Method
Mutable transcripts let users issue natural-language edit requests that revise the full conversation history, updating prior user and assistant messages.
Source: §2 · p. 3Results
Takeaways & Limitations
The findings provide initial evidence that user-driven revision can improve interaction quality and maintain a more current conversational state while reducing obsolete retained context.
Source: §6 · p. 9, §7 · p. 9Full-transcript rewriting ensures consistency but adds computational overhead because output-token counts scale with conversation length.
Source: §3.1 · p. 5
Abstract
from arXiv · showhide
Contemporary large language model (LLM) chat systems treat conversation history as an immutable sequence of turns that defines the model's working context. However, user intent in real interactions is not static: it evolves through correction, refinement, and shifting constraints. This mismatch between dynamic intent and static transcripts can result in context pollution, where outdated or irrelevant information persists and continues to influence subsequent responses. We introduce mutable transcripts, a new interaction paradigm that enables users to revise prior turns through natural language edit requests, allowing the conversation history itself to be updated rather than appended. This reframes the transcript from a passive record into an editable representation of conversational state. We present a working prototype that integrates transcript-level revision into a standard chat interface and evaluate its feasibility through a controlled user study (n=17) and an illustrative transcript analysis of representative interaction scenarios. Participants significantly preferred mutable transcripts over standard chat across measures of clarity, confidence, and ease of use, with reduced intent to restart conversations. Transcript analysis of representative user study conversations shows that mutable transcripts can reduce conversation length and eliminate obsolete retained context. These findings provide initial evidence that user-driven revision of conversational history can improve interaction quality and help maintain a more current representation of user intent. The source code and prototype can be accessed at https://github.com/QxLabIreland/ReChat
1 Introduction
The paper argues that immutable chat histories retain context even as user intent evolves, creating a mismatch that mutable transcripts aim to address. It introduces user-directed revision within the familiar chat interface and frames the work as a feasibility study.
1.1 How Chat Context Works
- Chat systems pass the growing conversation history back to the model, making that history both the thread’s context and a technical and UX constraint.The paper describes many systems as stateless between turns, with the transcript serving as their only memory.Source: §1.1 · pp. 1–2
1.2 Context Pollution
- Context pollution is the persistence of outdated, contradictory, or irrelevant transcript information that can continue influencing responses after user intent changes.The paper attributes this persistence to appending corrective turns rather than revising stale concepts.Source: §1.2 · p. 2
1.3 The Immutability Constraint
- Prior approaches manage context through system-driven truncation, summarization, or retrieval, while branching and other interfaces either preserve stale history or leave the chat metaphor.The paper identifies a remaining question about users’ experience of directly revisable history, while setting broader security and accountability issues outside its focus.Source: §1.2 · p. 2, §1.3 · p. 2
- The paper proposes natural-language revision of prior conversational state within chat and demonstrates feasibility through a prototype, controlled study, and illustrative transcript analysis.It describes the work as a concept and feasibility study, not a definitive empirical comparison across interaction paradigms.Source: §1.3 · pp. 2–3
2 Mutable Transcripts
Mutable transcripts treat conversation history as editable conversational state, so users can revise it as their intent changes. A natural-language edit request transforms the full transcript, shifting interaction from appending corrections to directly updating retained context.
2 Mutable Transcripts
- A mutable transcript treats conversation history as editable state that can be revised as user intent evolves.This contrasts with treating the transcript as an immutable log.Source: §2 · p. 3
- A natural-language edit request operates over the full history and produces a revised transcript updating both user and assistant messages.The paper represents the transformation as T ′ = f(T, e), where T is the original transcript and e is the edit instruction.Source: §2 · p. 3
- Direct revision replaces append-only correction, allowing outdated or contradictory information to be removed or updated so retained state better reflects current intent.The approach supports retroactive correction, constraint injection, and context pruning without manually editing individual messages or restarting.Source: §2 · p. 3
- The paper examines feasibility through a working prototype integrated with an LLM, case studies, and a controlled user study.Source: §2 · p. 3
3 System Design
The system adds an Edit History mode to a standard chat interface: ordinary prompts append to the transcript, while edit instructions revise it. Its prototype rewrites the full transcript, a choice that supports consistency but increases generation cost with conversation length.
3 System Design
- The standard chat interface offers an append-only default mode and an Edit History mode for transcript-level modification.In edit mode, the interface signals revision, rewrites the full transcript, and displays the updated conversation.Source: §3 · p. 3, Figure 1 · p. 4
- Natural-language editing keeps transcript revision within familiar chat interaction patterns and requires only a mode selector beyond the standard interface.Source: §3 · p. 3
3.1 Architecture
- In edit mode, the system supplies the full transcript and modification instructions to the model, then replaces the original transcript with the generated revision.The revised transcript becomes the conversational state for subsequent interactions, removing outdated or contradictory information rather than retaining it.Source: §3.1 · pp. 3–4, Figure 2 · p. 4
- Full transcript rewriting is a prototype design choice, not a requirement of mutable transcripts, and its output-token count scales with conversation length.Structured diffs, localized updates, or retrieval-based recomposition are proposed as more efficient alternatives for reducing latency and generation cost.Source: §3.1 · p. 5
4 Transcript-Level Operations
Mutable transcripts treat conversation history as editable state, enabling retroactive correction, context pruning, and constraint injection instead of merely appending corrective turns.
4 Transcript-Level Operations
- The scenarios illustrate transcript-level operations that revise history to maintain a more current representation of user intent.The section notes that Appendix E describes additional operations enabled by treating transcripts as editable state.Source: §4 · p. 5, §4.3 · p. 5
4.1 Retroactive Correction
- A natural-language edit can correct an earlier mistake and update all affected downstream turns to align with the corrected information.The example changes a question’s year from 2021 to 2022 and revises subsequent responses.Source: §4.1 · p. 5
4.2 Context Pruning
- Users can remove an irrelevant or misleading detour from the transcript while preserving the rest of the thread.The example removes a discussion of climate change’s economic impact to prevent obsolete context from influencing later responses.Source: §4.2 · p. 5
4.3 Constraint Injection
- Users can apply new constraints across prior messages so they remain consistent throughout the conversation without restarting.The example applies on-device-only, no-cloud, and WCAG AA requirements across the discussion.Source: §4.3 · p. 5
5 User Study
A 17-participant, counterbalanced study compared standard chat with mutable transcripts across corrective tasks. Participants preferred the mutable interface across all five measures, while representative transcript pairs showed shorter histories and less obsolete context.
5 User Study
- Seventeen participants completed both conditions in a counterbalanced within-subjects design, with ten experiencing A→B and seven B→A.The study used a controlled comparison across three tasks and sought to mitigate learning and carryover effects.Source: §5 · pp. 5–6
5.1 Survey Structure
- Participants completed three corrective tasks under both conditions, covering retroactive correction, constraint injection, and context pruning.The study used real-world scenarios in which participants later needed to correct or constrain earlier assumptions.Source: §5.1 · p. 6
- After each task, participants rated both conditions on transcript cleanliness, state clarity, confidence, restart intent, and ease of use.Responses used Likert scales, including 1–7 scales for ease of use and restart intent.Source: §5.1 · p. 6
5.2 Results
- All five measures favored mutable transcripts over standard chat, with statistically significant differences across measures (all p < 0.001).Measures included transcript cleanliness, state clarity, confidence, restart intent, and ease of use; Figure 3 reports combined preferences.Source: §5.2 · pp. 6–7, Figure 3 · p. 7
5.3 Transcript Analysis
- Across representative scenarios, mutable transcripts reduced average length from 8 to 4 turns (-50%) and tokens from 581 to 238 (-59%), while baseline histories retained 71.4% obsolete tokens.The analysis compares paired transcripts under standard chat and mutable conditions and is illustrative rather than a large-scale benchmark.Source: §5.3 · pp. 7–8, Table 1 · p. 8
5.4 Correction Method Preference
- Follow-up corrections were the most common current strategy (94.1%), while 88.2% said they would use Edit History if available.Other reported strategies included copying and modifying a prior prompt (70.6%), editing prior messages (35.3%), and restarting (23.5%).Source: Figure 4 · p. 8, §5.4 · p. 8
6 Discussion
The discussion connects mutable transcripts with cleaner conversational state and reports that participants associated revision with better interaction quality and continuity.
6 Discussion
- Users commonly rely on follow-up corrections and prompt rewriting, reflecting the limits of immutable conversation histories.Source: §6 · p. 9
- Revising earlier transcript content was associated with clearer conversations, greater confidence in outputs, and ease of use.Source: §6 · p. 9
- Lower restart intent suggests mutable transcripts may help preserve continuity by letting users repair and refine an existing thread.Source: §6 · p. 9
- The paper frames mutable transcripts as preserving conversational progress while reducing obsolete state and transcript growth over iterative corrections.They are not primarily intended to improve immediate task success in short interactions.Source: §6 · p. 9
7 Conclusions and Future Work
The paper presents mutable transcripts as editable conversational state and reports user-study findings and illustrative examples. It also identifies practical trade-offs and directions for further evaluation.
7 Conclusions and Future Work
- Mutable transcripts treat conversation history as editable conversational state, and the authors present a prototype, structured case studies, and a controlled user study.They describe user-driven revision as a way to manage evolving intent while preserving the conversational interaction model.Source: §7 · p. 9
- The authors identify risks involving authorship, accountability, trust, ambiguous edits, inconsistent changes, and loss of useful information.Suggested safeguards include previews, undo, version histories, and visual diffs; rewriting the full transcript may add latency, and immutable-record contexts may be unsuitable.Source: §7 · p. 9
- Future work should test controlled editing in longer, more naturalistic conversations and examine integration with system-level context management.The authors frame mutable transcripts as complementary to existing context-management approaches.Source: §7 · p. 9
A.1 Prompt Template for Edit History Mode
- The Edit History prompt asks the model to rewrite conversation history to satisfy an instruction, while preserving Markdown formatting and returning a JSON array.The default-chat prompt is a concise instruction to act as a helpful assistant.Source: §A.1 · p. 11, §A.2 · p. 11
B User Study Design and Materials
- The voluntary study compared standard chat and Edit History across retroactive correction, constraint injection, and context pruning, using task follow-ups and Likert questions.Questions covered transcript cleanliness, state clarity, confidence, restart intent, and ease of use; participant-level responses were made available for inspection and reproducibility.Source: B User Study Design and Materials · p. 11, Likert Questions Asked After Each Task · pp. 12–13, §C.1 · p. 13
B.1 Example Task Instructions Given to Participants
- The example retroactive-correction tasks ask participants to revise an Ireland GDP conversation to refer instead to Iceland and then to 2022, with and without Edit History.The example instructs participants to review the thread after each condition.Source: Task 1A - Retroactive Correction… · p. 12, Task 1B - Retroactive Correction (with… · p. 12
C.2 Qualitative Feedback from Participants
- Participants described Edit History conversations as cleaner, less cluttered, easier to reread, and more manageable, especially for well-defined or unnecessarily long tasks.Some also found the feature quick and easy to use.Source: §C.2 · p. 13
- Participants also reported that rewriting could remove useful original information, hinder before-and-after comparison, and be unnecessary for exploratory conversations.Comments called for greater transparency and control, including diffs, clearer constraint reminders, and version history.Source: §C.2 · p. 13
C.3 Additional Survey Results
This supplementary section reports survey context and self-reported chatbot use and correction behavior among respondents. Its tables cover participant fields, chatbot use, editing needs, and likely feature adoption.
C.3 Additional Survey Results
- Table 2 reports the professional or academic fields of the 17 participants.Source: Table 2 · p. 13
- Table 3 reports how often respondents used LLM chatbots for work, study, or personal tasks, while Table 4 reports chatbots they knew or used most often.Table 4 allowed multiple selections, and percentages are calculated over respondents rather than selections.Source: Table 3 · p. 14, Table 4 · p. 14, §C.3 · p. 14
- Tables 5–8 cover respondents’ need to edit prior chatbot inputs, actions taken, prior encounters with similar situations, and likelihood of using Edit History.Source: Table 5 · p. 14, Table 6 · p. 14, Table 7 · p. 14
D Transcript Analysis Data
The supplementary transcript analysis provides representative paired conversations for comparing standard append-only chat with mutable transcripts. The authors characterize the analysis as illustrative rather than statistically powered.
D Transcript Analysis Data
- The dataset contains one pair of conversations for each of three scenarios: retroactive correction, constraint injection, and context pruning.Each pair compares the same task in standard append-only chat and mutable-transcript conditions.Source: D Transcript Analysis Data · p. 15
- Each transcript includes the full message sequence, the revised transcript when applicable, token counts, and annotations of obsolete tokens.Obsolete tokens are defined as belonging to turns superseded by later corrections or constraints.Source: D Transcript Analysis Data · p. 15
- The selected transcript pairs illustrate structural effects under controlled conditions but do not represent aggregate participant behavior or a statistically powered evaluation.Source: D Transcript Analysis Data · p. 15
- The authors suggest larger datasets and automated benchmarks to quantify effects on context efficiency and downstream model performance.Source: D Transcript Analysis Data · p. 15
E Additional Transcript Operations
The section describes additional operations enabled by treating the transcript as editable state. These examples include expanding, reframing, translating, restyling, redacting, and importing conversations.
E Additional Transcript Operations
- Edit History can simulate additional dialogue turns, generating both questions and answers for activities such as debate simulation or interview preparation.Source: E Additional Transcript Operations · p. 15
- Users can retrospectively reframe messages in different emotional tones to explore how emotional context influences dialogue.Source: E Additional Transcript Operations · p. 15
- Users can request translation or retrospective style changes across the conversation, such as switching language or making it more formal.Source: E Additional Transcript Operations · p. 15
- Users can request redaction of sensitive details with consistent placeholders while updating the transcript to remain coherent for sharing.Source: E Additional Transcript Operations · pp. 15–16
- Edit History can also load an external conversation into the current chat context for further editing.Source: E Additional Transcript Operations · p. 16
F Limitations
The limitations span computational cost, a missing comparison with branching, reduced recoverability of overwritten context, and unresolved security and trust risks.
F.1 Computational Overhead of Transcript Rewriting
- Transcript edits require regenerating the full history, adding latency and computational cost that may become inefficient in longer interactions.Revised transcripts may be more compact for later turns, but editing carries this overhead.Source: §F.1 · p. 16
F.2 Branching Comparison
- The study does not empirically compare mutable transcripts with branching interfaces, leaving their interaction trade-offs unevaluated.Branching preserves prior context, whereas mutable transcripts revise it.Source: §F.2 · p. 16
F.3 Loss of Useful Context
- Overwriting turns can discard useful alternatives or intermediate reasoning, making prior versions harder to compare or restore.Version history, undo, or diff-based views are suggested as complementary mechanisms.Source: §F.3 · p. 16
F.4 Security Risks
- Retroactive edits could insert misleading instructions that influence future responses, while making the assumptions behind responses harder to understand.The prototype does not directly address these risks; proposed safeguards include provenance tracking and constrained editing policies.Source: §F.4 · p. 16