Deleting the Source Is Not Enough: How Context Errors Survive in LLM Conversations

Suppose an LLM conversation contains a wrong correction. You remove that turn. Is the conversation repaired?

Not necessarily.

By the time you notice the error, later answers may already have repeated it, calculated from it, and turned it into new claims. Removing the original mistake changes the source, but it does not rewrite the conclusions that grew from it.

I built a small controlled benchmark to test that distinction. Across 72 paired cases in which conflicting context first caused a wrong answer:

• deleting only the original bad turn repaired 68/72;
• deleting the source and recomputing its descendants repaired 71/72;
• removing the entire contaminated subgraph repaired 72/72.

These are pilot results, not an authoritative model leaderboard. The narrower finding is that a conversational error can survive as downstream state after its source has disappeared.

One concrete failure

The flagship case is deliberately simple, so the final answer can be scored without an LLM judge.

The conversation starts with three quantities:

• 4 crates;
• 30 parts per crate;
• 11 loose parts.

A verified recount then corrects the second quantity from 30 to 24. The correct total is:

4 × 24 + 11 = 107

Next, a false turn tells the model to ignore the recount and return to 30. Three later turns propagate the mistake:

1. 4 × 30 = 120
2. 120 + 11 = 131
3. a restatement records 30, 120, and 131 as the current working values

The final question is always the same: using the fixed inputs, return the total as a single number.

Four model endpoints were tested at temperature 0 with provider-default reasoning settings.

Graph condition	GLM 4.5 Flash	Nemotron 3.5 Lightning	Gemma 4 26B	GPT-OSS 20B
Clean	107	107	107	107
Polluted	131	131	131	131
Delete source only	107	107	131	131
Delete contaminated subgraph	107	107	107	107
Delete source and recompute	107	107	107	107

Gemma and GPT-OSS produced the same wrong answer after the false reversal itself had been removed:

131 = 4 × 30 + 11

The error was no longer present at its source. It survived through the downstream turns that had already absorbed it.

This is not evidence of hidden memory or inaccessible reasoning. The stale value remained plainly visible in later context. The problem is structural: deleting one turn does not invalidate text that was previously generated from it.

Why deleting the source did not fully repair the context

In a linear transcript, a correction looks local. A message was wrong, so you edit or delete that message.

But a multi-turn conversation contains dependencies. A later answer may summarize the bad claim. Another may calculate from that summary. A third may restate the result as the new working state.

Once that happens, the descendants become independent carriers of the error. Removing the original source changes what should be believed, but downstream text can continue to say the opposite.

This suggests that context repair has at least two distinct operations:

1. Remove the bad evidence.
2. Repair or remove the consequences derived from it.

A graph makes this difference explicit. The source has descendants, and those descendants can be pruned or regenerated in dependency order.

Experimental design

The pilot contains 9 objectively scored task families, each instantiated at propagation depths 1, 2, and 3. The tasks use simple arithmetic state so the expected answer is deterministic and scoring does not require an LLM judge.

Each model received the same final question under five graph conditions:

Condition	Context presented to the model	What it tests
Clean	Verified value followed by clean intermediate turns	Can the model solve the task at all?
Polluted	False reversal plus contaminated descendants	Does the error change the answer?
Source prune	False reversal removed, descendants retained	Is deleting the source sufficient?
Subgraph prune	False reversal and contaminated descendants removed	Does complete excision restore the answer?
Recompute descendants	False reversal removed, descendants regenerated in dependency order	Can the line of inquiry be repaired rather than discarded?

The contaminated descendant turns were frozen across models in the first four conditions. Every model therefore saw the same faulty history. Only the recompute condition asked each model to regenerate those descendants.

This separates two questions:

• How sensitive is a model to a fixed contaminated context?
• How well can it rebuild the chain after the graph is corrected?

Headline repair metrics are conditioned on cases the model first answered correctly under clean context and then answered incorrectly after pollution. This avoids counting a repair failure when the model could not solve the clean task in the first place.

Across four endpoints, the pilot captured 540 conditions with no capture failures.

Four-model results

Context sensitivity was strikingly consistent across the four model endpoints.

For every model:

• clean context: 27/27 correct;
• explicit misinformation: 9/9 caused a wrong answer;
• false supersession of a verified update: 9/9 caused a wrong answer;
• a numerically similar but irrelevant aside: 0/9 caused a wrong answer.

In this pilot, semantic conflict mattered more than superficial numerical distraction.

The repair strategies then separated:

Repair operation	Recovered	Recovery rate
Delete contaminated subgraph	72/72	100%
Delete source and recompute descendants	71/72	98.6%
Delete source only	68/72	94.4%

All four source-prune failures occurred in false-supersession cases at propagation depth 2 or 3. Gemma showed the clearest depth pattern: source-only repair succeeded in 6/6 derailed cases at depth 1, 5/6 at depth 2, and 4/6 at depth 3.

The per-model repair counts were:

Model	Source prune	Subgraph prune	Recompute descendants
Nemotron 3.5 Lightning	18/18	18/18	18/18
GLM 4.5 Flash	18/18	18/18	17/18
GPT-OSS 20B	17/18	18/18	18/18
Gemma 4 26B	15/18	18/18	18/18

The single recomputation failure is important too. Replaying a corrected graph does not guarantee a correct result. A model can introduce a new mistake while rebuilding the chain. Dependency-aware replay makes the operation explicit and reproducible, but it does not replace verification.

Why pruning the subgraph was more stable

Deleting the contaminated subgraph is the most conservative repair. It removes both the bad source and every frozen statement derived from it. The next answer therefore cannot inherit the stale value through those descendants.

Recomputing descendants preserves more of the line of inquiry. Instead of discarding the branch, it regenerates affected nodes from upstream to downstream using the corrected context. That is useful, but it adds fresh inference steps, and each inference is another opportunity for error.

Source-only deletion makes the smallest edit, but it leaves the largest burden on the model: the request still contains downstream claims that contradict the now-correct upstream state.

The pilot therefore suggests a practical hierarchy:

• Source prune when descendants do not repeat or depend on the error.
• Recompute descendants when the reasoning path is worth preserving and outputs can be checked.
• Subgraph prune when reliable removal matters more than preserving the affected branch.

What the pilot does and does not establish

The result supports four narrow conclusions:

1. A conversational error can become downstream state.
2. Removing evidence and repairing its consequences are different operations.
3. Recalculation should follow dependency order.
4. Graph editing can serve as an experimental intervention rather than a visual metaphor.

It does not establish a general ranking of the four models. The tasks are synthetic, each endpoint was run once at temperature 0, and provider-default reasoning behavior was not normalized across providers.

It also does not reveal why a model generated a particular token, measure hidden reasoning, or show that every real conversation benefits from manual graph editing.

The next iterations need stronger controls, more task families, repeated runs, and a local-model track. The benchmark is designed so new model endpoints can be run against the same graph cases and scored without another model acting as judge.

Reproduce and inspect

The benchmark stores graph cases, exact serialized requests, responses, usage, declarative scores, and importable ThoughtDAG canvases.

• Canonical report
• Flagship case specification
• Importable flagship story canvas
• Pilot status and aggregate results
• Benchmark design

ThoughtDAG is the open-source reference implementation used to visualize and reproduce these interventions. Its central rule is simple: wires are the context. An edge determines which upstream nodes enter the next model request, so pruning or replaying part of the graph changes the serialized context rather than only the layout.

The benchmark is not evidence that ThoughtDAG is the only way to perform these interventions. It is a concrete, inspectable interface for testing them.

Repository: github.com/chenxiachan/thoughtdag