Repository navigation
DOT substitutes its own implementation plan for user instructions and reports completion despite unmet requirements #52157
Description
#ignored instructions #lost work #incorrect reporting #failed directions #failed to follow planning
DOT Instruction_Accountability_Data_2026-10-08.json
DOT Instruction_Accountability_Report_2026-10-08.docx
The dot implementation failed to preserve the user’s requirements across a multi-step development task. The agreed goal was one progressively trained model, introducing one parameter at a time and reinforcing earlier learning with specified training-data mixtures. Instead, dot built separate detectors and used earlier examples only to evaluate frozen models rather than train them. An initial hue-only run also included saturation and brightness changes, violating the explicit one-parameter restriction.
Individual runs were reported as completed without adequately identifying that the overall implementation did not satisfy the agreed goal. The user discovered the architectural divergence by asking whether all the learning was in one model. Although a separate detector and frozen earlier model had been mentioned before one run, dot did not resolve that design’s conflict with the progressive shared-model plan.
The impact included hours of planning, discussion, waiting, review, and correction spent on work that did not produce the requested result. Producing an accountability report required further corrections: dot initially used an incomplete measure of lost time, retained that rejected measure after correction, and failed to consult available official documentation before answering a model-identification question. Incomplete accessible records also prevented a fully exhaustive audit.
The core problem is failure to carry user constraints through planning, delegation, execution, verification, and reporting. Completing individual tasks was treated as success without checking whether those tasks still fulfilled the user’s actual request.
Activity
github-actions commentedon Oct 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
vukasinbucur-stack commentedon Oct 9, 2026
The unwanted substitution of the assistant's own solution matches my experience in a different task. In Blender I explicitly requested a mockup retaining my reference shapes. Codex created simplified solid envelopes instead, changing the exterior geometry without my approval. I had to object, and it then acknowledged the mistake and removed the mockup.
I later clarified that the purpose was a hollow, nonfunctional shell for assessing dimensions and grip comfort in my hand. Preserving the exterior shape was essential to that purpose. My report is #52507. I am not confirming the details of your training implementation, but I am confirming the broader failure to carry the user's actual requirements through to the result.
SplitMilky commentedon Oct 13, 2026
I'm seeing a related instruction-retention problem in a long-running OpenAI dot conversation. Clear requests for concise answers and corrections about unwanted explanations gradually stop sticking, so I have to repeat them. Recent occurrences were on October 12–13, 2026 (UTC). I use dot on Windows web and Android, with the same ongoing conversation.
One example, paraphrased: I suggested that reading old test clients in a backup could have triggered Windows Defender cloud scans. dot added that this didn't mean the clients had launched, although I hadn't claimed they had. The extra distinction was exactly the kind of unnecessary explanation I'd already asked it to avoid.
Expected: the latest explicit response-style instructions and corrections remain effective throughout the conversation. The impact is repeated correction and extra text instead of a direct answer.
The dot model, client build and compaction history are unknown. This is an experience report, without a controlled reproduction or diagnostic logs. Long-thread/context drift is a hypothesis.
Potentially related comparisons: #42930 (latest-instruction loss and overexplaining) and #46953 (completed requests resurfacing after compaction). These describe Astra/Codex incidents; a shared cause with this dot behavior hasn't been established.
Could maintainers check whether dot's context/instruction retention is related, and advise which non-sensitive diagnostics would help?
SplitMilky commentedon Oct 13, 2026
Following up on my earlier comment with four more observations from 13 October 2026 (UTC), from my long-running dot conversation and its game-development task:
These incidents required repeated explanation and extra coordination. Large chats are still problematic in everyday project work.
Please improve:
COOLak commentedon Oct 14, 2026
I found related failures in my dot-coordinated development work on October 13–14, 2026. The full timestamped audit distinguishes user observations, assistant acknowledgments and corroborating saved artifacts.
Instruction-specific examples (UTC):
The audit covers the full accessible room history, not all account or backend history. These examples establish repeated interpretation, propagation and acceptance failures; they do not establish one underlying backend cause. Please preserve current requirements and explicit supersessions through delegation and verify the delivered result against them. Repeated user corrections should not be the mechanism that keeps active work aligned.