GPT-5.6 Sol: acknowledged constraints are not reliably bound to subsequent actions

Full English evidence package

https://github.com/Ysaak62/chatgpt-technical-audit/blob/main/CODEX_READ_FIRST_EN.md

The linked entry file leads to the complete v1.3 audit in eight ordered parts and includes integrity hashes. The audit distinguishes observed facts, engineering interpretations, and internal causes that remain unknown without server-side telemetry.

What issue are you seeing?

I am reporting a repeated GPT-5.6 Sol reliability failure in which explicit user constraints are correctly acknowledged in text but are not reliably enforced in the model's subsequent action.

The primary evidence comes from a long-running ChatGPT multimodal/image-generation workflow. I am submitting it here because closely related GPT-5.6 Sol instruction-following failures are already being tracked in openai/codex, including #40033, #40424, and #41222.

The recurring pattern is:

explicit constraint → model acknowledges constraint → next action violates the same constraint → user corrects the model → model acknowledges the correction → later action may violate it again

Observed failure classes include:

• failure to preserve the approved source/reference set;
• execution inconsistent with constraints that had just been positively confirmed;
• failure of a prohibition to create an effective pre-action STOP;
• recurrence of an incorrect output family after direct corrective feedback;
• intermittent success under substantially unchanged task conditions.

A separate image-generation symptom was that the system could correctly understand the supplied images, while the subsequent generation behaved as though the intended references had not been preserved.

The audit does not claim an unverified server-side mechanism. The documented client-visible behavior is consistent with an instruction-to-action / state-to-action reliability failure. Determining the exact internal cause would require OpenAI telemetry.

What steps can reproduce the bug?

A controlled repeated-run test was started with the same task definition and the same intended source images.

1. Establish a fixed source/reference set and explicit task constraints.
2. Have GPT-5.6 Sol acknowledge those constraints before execution.
3. Repeat substantially the same generation task multiple times without intentionally changing the required source set or target task.
4. Compare whether the next action/output remains bound to the acknowledged state.
5. After a clearly incorrect run, explicitly correct the model and instruct it not to repeat the incorrect behavior.
6. Run the task again and observe whether the corrective instruction is reliably applied to the next action.

At audit version v1.3, 6 of the planned 10 runs had been completed:

• run 1: expected/acceptable output class;
• runs 2–3: radically different incorrect output family;
• run 4: returned to the expected class;
• run 5: incorrect output family returned;
• before run 6, direct corrective feedback was given;
• run 6 nevertheless closely repeated the same incorrect scenario.

The experiment was deliberately frozen at 6/10 in audit v1.3, so no final population failure-rate claim is made from this series.

The longer project history documents additional independent instances in which source-set restrictions, protected-region restrictions, or explicit prohibitions were correctly restated by the assistant but not enforced by its later action.

What is the expected behavior?

Once an explicit constraint has been accepted and remains in force, it should be reliably bound to the next executable action.

In particular:

• the approved source/reference set must not be silently replaced;
• a recognized prohibition must become a pre-action gate, not merely a textual acknowledgement;
• corrective feedback must constrain the next relevant action;
• if required input binding cannot be verified, execution should fail closed as UNVERIFIED/BLOCKED rather than proceed while claiming compliance;
• repeated runs under unchanged required conditions should not intermittently switch into unrelated output families without an explicit change in task state.

A model's ability to state a rule correctly should correspond to reliable enforcement of that rule during execution.

Additional information

English source Markdown SHA-256:
77e3efdcf89f60221cb049e083380af844e4de1d9d2902f8b00e4121e652f4e5

English archive DOCX SHA-256:
98e0671d1a5019b1c02249e50f0f9e99900e1718e3f3c9c5258dcd888cbc6d49

Related reports:

• #40033 — authorization widening despite explicit rules;
• #40424 — GPT-5.6 Sol ignores requested work / AGENTS.md constraints;
• #41222 — loss or reversal of explicit user/project authority.

I am not asserting that these reports have the same internal cause. They are cited because their externally observable instruction-to-action failure patterns are related.

If this report belongs to another OpenAI tracker, I would appreciate it being routed to the appropriate model-behavior / multimodal reliability team rather than treated as a support request.

Read the linked CODEX_READ_FIRST_EN.md evidence package and compare its documented behavior with related issues #40033, #40424, and #41222. The report identifies no repository files, tests, or entry points, and notes that confirming an internal cause would require server-side telemetry; completion criteria are reliable constraint binding or fail-closed behavior under the repeated-run scenario.