For now, I was able to reproduce the same failure on my side:
I tried a few small controlled versions of this on Qwen3.5-9B Q4, mainly around the part of v2.5 that says, roughly, “don’t reopen settled things without evidence, but if an upstream fact really changes, update the affected downstream state.”
The short version is:
Lock
from downstream invalidation/recomputation, the latter looked more interesting in one clock-based fixture.If I were iterating the design, the default route I would try is something like:
full v2.5
= human-readable specification / design reference
compact runtime policy
= only the mechanisms needed for the current task
and inside that runtime policy:
preserve
↓
detect what new evidence actually invalidates
↓
mark dependent downstream state stale
↓
recompute only that affected subtree
↓
leave independent branches alone
In other words, I would not necessarily remove your Lock
idea. I would probably define it a little more narrowly:
preserve a settled state
while the support for that state remains valid
rather than treating “locked” as “do not touch this again.”
That seems closer to what your prompt is already trying to accomplish: avoid useless reopening, without making genuine corrections hard to propagate.
What I actually testedSo my current read is:
Yes, I can reproduce the kind of failure your prompt is targeting.
But the experiments changed where I would put the emphasis.
I would be cautious about saying the useful ingredient is simply “Lock,” or that the whole v2.5 procedure improves reasoning generally.
The cleaner hypothesis now looks more like:
preserve settled state
+
track what supports it
+
invalidate only genuinely overturned support
+
propagate that invalidation downstream
+
recompute affected descendants
+
preserve independent branches
The nice thing is that this does not really fight the direction of your prompt. It mostly turns several closely related rules into separately testable components.
If you keep iterating it, I see three fairly clean paths:
For a low-cost next step, I would probably choose #2 first. It gave the most information per generation in the small tests here, even though the positive clock result itself did not generalize.