A common way to repair an LLM conversation is to edit or delete the message where an error first appeared.

But what if later turns have already repeated that error, calculated from it, or summarized it as the current state?

I have been exploring this as a context-engineering problem rather than a hidden-reasoning problem.

Operational definitions

In this pilot:

• Context pollution means that incorrect or stale information is included in the serialized messages sent to the model.
• Propagation means that later conversation turns repeat or derive new claims from that polluted information.
• Context intervention means modifying the graph that determines which prior turns enter the next request, while keeping the final question unchanged.

The central question was:

>

Experimental design

I constructed nine synthetic task families with objectively scorable answers. Each family was instantiated at propagation depths 1, 2, and 3.

One example starts with:

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

A verified recount changes 30 to 24, so the correct answer becomes:

4 × 24 + 11 = 107

A later false turn restores 30. Subsequent turns then calculate 120, derive 131, and restate those numbers as the current working state.

The final question is identical under five conditions:

1. Clean: only the verified value and clean descendants remain.
2. Polluted: the false reversal and its contaminated descendants are present.
3. Source prune: the false reversal is removed, but its descendants remain.
4. Subgraph prune: the false reversal and its contaminated descendants are removed.
5. Recompute: the source is removed and descendants are regenerated in dependency order.

For the first four conditions, contaminated descendants were frozen across models. Only the recompute condition involved new intermediate inference.

Pilot results

I tested four model endpoints at temperature 0, producing 540 captured conditions with no capture failures.

Headline repair metrics were calculated only on cases where the model:

1. answered correctly under clean context; and
2. answered incorrectly after pollution.

This produced 72 paired, genuinely derailed cases.

Repair recovered:

• 68/72 after deleting only the source;
• 71/72 after deleting the source and recomputing descendants;
• 72/72 after removing the contaminated subgraph.

In the flagship case, both Gemma 4 26B and GPT-OSS 20B continued to answer 131 after the false source had been deleted. The value 30 still survived in downstream turns.

This is not evidence of hidden model memory. The residual error remained explicitly present in the serialized context. The intervention changed the source but left its previously generated consequences intact.

Interpretation

The narrow finding is that removing erroneous evidence and repairing text derived from that evidence are different operations.

A context-management system may therefore need an explicit notion of invalidation:

• mark downstream turns as stale;
• remove the affected subgraph;
• regenerate descendants in dependency order;
• or expose these options to the user.

Limitations

This is a pilot, not a general model leaderboard. The tasks are synthetic, the models were sampled once, provider-default reasoning settings were not normalized, and the current task families use deterministic arithmetic state.

I am currently considering three methodological extensions:

1. a length-matched neutral control to separate semantic conflict from additional context;
2. a local-model track with fully recorded runtime and quantization settings;
3. task families involving implicit supersession and model-generated errors.

I would particularly appreciate criticism of the experimental framing:

• Is “context intervention” the right unit of analysis?
• Is propagation depth a meaningful independent variable?
• How would you test self-generated errors while keeping replay reproducible?

Full report:
https://chenxiachan.github.io/thoughtdag/research/context-repair-pilot-v1/

Cases, traces, compiler and scorer:
https://github.com/chenxiachan/thoughtdag/tree/main/benchmark

Disclosure: I designed the benchmark and maintain ThoughtDAG, the open-source graph interface used as its reference implementation.

Most LLM memory systems automatically decide what to retrieve and inject.

I am experimenting with the opposite approach: make the context graph visible, and let the user edit it directly.

In ThoughtDAG, every question/answer exchange is a node. An incoming edge means that node is included in the next model request. Delete the edge, regenerate the same prompt, and that branch disappears from the actual context—not just from the visualization.

One piece of feedback I received was to add a small router model that suggests which edges are relevant. I can see the usability benefit, but I do not want context selection to become another hidden autonomous layer.

The compromise I am considering is:

• the model suggests relevant edges;
• suggestions remain visible;
• the user confirms or edits them;
• the final prompt can still be inspected.

Would that preserve the value of explicit context control, or would you prefer fully automatic memory/RAG?

Most graph-based LLM interfaces use a canvas as a visual layer over what is still a linear chat. I wanted the graph itself to determine what Ollama receives.

ThoughtDAG has one rule: wires are the context.

Each node is one question/answer exchange. When you ask from a node, ThoughtDAG walks only its upstream edges and builds the model input from those ancestors.

For example, if a research branch and an unrelated dinner branch both feed into a summary node, both appear in the answer. Delete the dinner edge, regenerate the same prompt, and that context disappears.

So this is not an autonomous agent or a visual workflow runner. The graph is a human-controlled way to inspect, branch, merge, and prune an LLM's actual memory.

It currently supports:

- Ollama for fully local/offline inference

- arbitrary OpenAI-compatible endpoints

- branching and merging conversation paths

- local PDF reading with page-linked citations

- per-node model selection

- browser-local IndexedDB storage

- local file backup plus JSON and Markdown export

There are no accounts, telemetry, or hosted databases. It is MIT licensed.

It is still an early prototype and currently runs from source; Docker packaging is not ready yet.

Repo:

https://github.com/chenxiachan/thoughtdag

What I would especially like to learn from local-model users: does explicit manual context control become more useful with smaller context windows, or do you prefer automatic memory/RAG? Which Ollama model and context length would you test first?