Um, from what I found when I tried it:
I think the experiment is getting more interesting once the question is split into a few separate layers.
The short version of my answers to your three questions would be:
| Question | My current take |
|---|---|
| What should be logged? | |
The graph operation is only part of it. I would log the exact request payload your harness sent, model/runtime identity, generation termination, raw output, and evaluator state. In particular, finish_reason / output-cap hits turned out to matter in a small check I ran. |
|
| When is manual pruning useful vs automatic memory/RAG? | |
| I would not make this a binary contest. Manual control seems especially useful for debugging, auditing, research interventions, and exceptional cases; automatic selection is better suited to routine scale; a hybrid where the system proposes and the human can inspect/override seems like a very natural third condition for ThoughtDAG. | |
| Worth testing across models/context sizes? | |
| Yes, but I would separate semantic content, position, actual input length, and model/backend rather than just increasing the nominal context window or adding more models at once. |
The framing that now makes the most sense to me is:
detecting that a branch is badandrepairing the context after that branch is already known to be badare different experiments.
Your current graph intervention is particularly clean as the second kind.
That distinction lets the current experiment stay narrow without asking it to solve the harder adjudication problem at the same time.
Something roughly like this:
intervention identity
↓
model/runtime identity
↓
execution outcome
↓
evaluation identity
source_prune
, descendant removal, replay, etc.)I would say client-observed request payload rather than assume that an OpenAI-compatible provider internally serializes it exactly the same way; the latter is often outside the experimenter’s visibility.
max_new_tokens
That last layer ended up being more important than I expected.
I tried a small matched-control run against the repair fixtures, and my first automated summary contained three apparent failures that were not actually context failures. All three outputs hit max_new_tokens=64
; the model had already computed the correct answer in prose, but the required final-number line was cut in the middle of the number.
I reran the exact same pinned payloads at 64 and 128 tokens. The old 64-token strings reproduced exactly and were prefixes of the 128-token generations; all three longer generations completed the correct answer.
So a small practical addition I would make to the trace format is:
hit_generation_cap
finish_reason
raw_response
parsed_answer
score
That makes it much harder for an evaluator artifact to masquerade as a context-repair failure.
The matched control I tried, including the scoring gotchaThe question that originally motivated the post — is a later correction enough, or should the earlier source leave the request? — actually seems to contain several possible interventions:
append a correction
remove the bad source
remove affected descendants
recompute affected descendants
They are not interchangeable.
A later correction asks the model to perform something like belief revision while contradictory or superseded material remains available. There is already evidence that this is non-trivial: the Belief-R work on belief revision found that models often struggle to revise prior inferences appropriately when new evidence arrives.
But ThoughtDAG gives you another experimental lever: instead of asking the model to resolve the conflict internally, you can alter the effective context before the request.
That makes a useful separation possible:
A. Which state is actually stale / wrong?
↓
B. Once it is known to be wrong, what must be invalidated?
↓
C. What, if anything, must be recomputed?
I would treat A as a detection/adjudication benchmark and B/C as a repair benchmark.
That seems especially helpful for the temporal cases. If the latest turn says “the correction was wrong; go back to the old value”, the model may have no independent evidence telling it that the latest turn itself is false. Calling that a failure to detect misinformation would require a different source of truth.
Calling the branch known-bad by the experiment and then asking what repair is necessary avoids that ambiguity.
This is also starting to show up as a distinct neighboring problem in recent agent-memory work. STALE separates state resolution from downstream policy adaptation, and the very recent Dependency-Guided Rollback Repair explicitly assumes diagnosed faulty memories and asks how to retract affected downstream state while preserving unaffected work.
I would not treat those papers as proving the ThoughtDAG result — the systems and memory semantics are different — but the decomposition is strikingly similar.
It gives a reasonably standard vocabulary for what your source/subgraph/replay comparison is probing:
fault diagnosis
!=
fault removal
!=
dependency invalidation
!=
selective recomputation
That is probably a stronger framing than trying to make the one-edge result carry all four claims.
This was also the part of my small run I found most interesting after the matched-length question was controlled.
Among the 18 cases where pollution changed a clean-correct answer:
source-only pruning 14/18
contaminated subgraph 18/18
Again, one model and a small controlled fixture set, so I would not generalize the rate.
But it is consistent with a simple structural failure mode:
bad source
↓
derived claim
↓
derived calculation
↓
summary / recommendation
Once the derived state has been materialized into later messages, deleting only the original source does not necessarily remove the stale downstream text from the next request.
That makes the existing distinction between source pruning, subgraph pruning, and replay/recomputation useful in its own right.
There is also a nice design trade-off here:
So rather than asking only:
“Does pruning work?”
I would probably preserve the more informative question:
What is the smallest repair that restores a valid downstream state without unnecessarily discarding unaffected work?
That seems compatible with the direction ThoughtDAG is already taking with staleness and dependency-order replay.
I would be hesitant to turn this into:
manual pruning vs RAG
which one is better?
because they optimize different things.
A rough split might be:
| Mode | Natural strength | Natural cost |
|---|---|---|
| Manual | ||
| inspectability, deliberate exceptions, debugging, research interventions, auditability | human attention | |
| Automatic | ||
| routine operation, scale, low interaction cost | false keeps / false removals can be less visible | |
| Hybrid | ||
| system does routine selection; human can inspect/override important cases | more UI/control-plane complexity |
The distinction between stored history and effective model input is already a practical implementation primitive. For example, the OpenAI Agents SDK exposes model-input filtering, and Claude context editing separates selective clearing from broader compaction.
So I do not think the interesting claim for ThoughtDAG needs to be:
“other systems cannot filter context.”
The more distinctive question seems to be:
What changes when context selection is visible, reversible, and expressed in the same graph the human is using to reason?
That gives manual control a possible value even when automatic selection is perfectly available.
It also suggests a fairly natural third condition if you ever want to study this:
automatic suggestion
+
human-visible accept / reject / override
Recent work on controllable memory use points in a similar direction. For example, SteeM studies user control over how strongly an agent should rely on memory, rather than assuming maximum memory use is always desirable.
Another separation I like here is:
keep this history?
!=
show it to the human?
!=
include it in this model call?
Your current “remove the edge without deleting the earlier work” behavior is useful precisely because those do not have to be the same decision.
A possible evaluation matrix for manual / automatic / hybridI think this is worth testing across models and larger contexts.
I would just distinguish nominal context capacity from actual input length.
An 800-token experiment on a model advertised as 128K context is still an ~800-token experiment; changing the model’s maximum window does not by itself test long-context behavior.
There are at least four variables that can otherwise get mixed together:
semantic treatment
position
actual input length
model / backend
The first cheap sequence I would use is probably:
semantic control
clean / polluted / matched-neutral / repaired
position control
move the same contaminated material earlier / middle / later while holding content as fixed as possible
actual length control
increase real input length while preserving the intervention
model/backend replication
then repeat a small selected panel across deliberately different model families/runtimes
There is good reason to isolate 2 and 3. Lost in the Middle showed that the position of relevant information can strongly affect long-context performance, while Context Length Alone Hurts LLM Performance Despite Perfect Retrieval found degradation from increasing input length even when retrieval of the relevant evidence was effectively controlled.
So if an edge deletion changes both content and where everything else lands in the request, those are alternative explanations worth keeping visible.
The matched-neutral condition is one cheap way of removing a large part of that ambiguity before paying for a large model sweep.
A compact decision tree I would use when reading the resultsOne thing I think the original post gets right is explicitly saying that this is not attention visualization or an explanation of why a particular token was generated.
An edge here establishes something concrete:
an upstream node was or was not serialized into the downstream request.
That is a useful provenance/exposure relation.
It does not automatically establish:
every statement in the child is semantically dependent on that parent,
or:
the model internally represented that graph edge as the cause.
There is a nearby research vocabulary for this. ContextCite, for example, treats context attribution as a perturbation problem: alter subsets of the context and measure what happens to generation.
So I would be comfortable calling the ThoughtDAG operation an observable context intervention or a counterfactual context ablation.
That is already useful without promoting it into a hidden-mechanism explanation.
The current controlled arithmetic cases are useful because they make the intervention easy to audit.
The trade-off is that many of them share a similar computational shape.
So, if the next goal is generalization, I am not sure the highest-information next step is simply “more models × more nearly identical arithmetic cases.”
A small number of different dependency motifs might tell you more:
ratio / division
conditional choice
lookup → transformation
multi-source aggregation
multi-step plan with a reusable intermediate result
The especially interesting cases for replay would be ones where a descendant contains useful work that should not simply be thrown away.
That would separate:
“delete everything downstream and solve the easy final arithmetic again”
from:
“invalidate exactly the work that depended on the bad premise, then reconstruct the useful intermediate state.”
For a later natural-language track, something like LongMemEval gives useful categories such as multi-session reasoning, temporal reasoning, and knowledge updates. I would keep that as a separate generalization lane rather than weakening the controlled synthetic lane by trying to make one benchmark do both jobs.
In my Qwen run, the explicitly irrelevant-distractor cases produced:
0/9 derailments
while the misinformation and temporal-supersession families each derailed all nine of their tested k=1/2/3 cases.
Given how explicitly the fixtures identify those asides as unrelated, I would personally read that lane as a useful negative control / sanity check:
these clearly marked irrelevant asides did not land in this short controlled setup.
I would not generalize it to:
irrelevant context is harmless.
That distinction also keeps it compatible with the broader long-context literature, where irrelevant material and length can certainly hurt under other conditions.
This is not a problem with the current text-only intervention, but it may matter as ThoughtDAG grows more agentic.
Some model APIs impose structural constraints on conversation history. A tool invocation and its result, for example, may have to remain paired in a particular order. Arbitrarily removing one message can make the remaining request invalid rather than merely changing its semantics.
So a future graph may need the notion of an atomic pruning unit or protocol-aware context transformation:
semantic node
vs
provider-valid message unit
That is probably only worth worrying about when tool traces themselves become editable context, but it seems like a useful boundary to keep in mind.
Putting all of that together, I think the result is already more interesting than:
“I removed an edge and the answer changed.”
The more specific experiment I see is:
Given a context state that is known to contain a contaminated branch, what is the smallest observable context intervention that restores a correct downstream state, and what useful work can be preserved?
That gives you several cleanly separable research questions without requiring the UI, the memory policy, the misinformation detector, and the model’s hidden reasoning to all be evaluated at once.
And for the broader human-vs-system question, I would keep the thing that seems genuinely distinctive here: the branch can remain part of the visible history while being excluded from the active model request.
That means the design does not force remembering, showing, and using right now to be the same operation.
To me, that is probably the most interesting place to compare human-directed, automatic, and hybrid context control.