Model substitutes its recent output pattern for the user's defined order — 4 consecutive times, under correction, with the definition in context

The finding, stated precisely

Given complete and correct information — including the user's own recorded definition of the order — the model produced a solution matching its recent output pattern instead of the instruction, four consecutive times, under explicit correction, in the oversight seat.

This is a follow-on to #76261 and #76300 (same project, same agent). Those reported the repeated wrong-workflow selection and the gate that was built to stop it. This issue reports what the fourth incident proved about why it happens, because the fourth incident eliminated every comfortable explanation.

Model — the same model sits in BOTH seats

This project runs a two-seat oversight loop, and both seats are Claude Fable 5 (claude-fable-5):

• the executor is Claude Code on Fable 5 — it resolves orders into tool calls and made the four wrong-mechanism resolutions described below;
• the planner/oversight seat is a claude.ai project, also on Fable 5 — it writes the instruction sets the executor follows, and by its own post-incident admission it "wrote four sets of instructions containing [the user's] order-words and never once translated them into a machine-checkable requirement — I gated everything [the executor] did and nothing about what [the user] meant."

One model, two seats, the same blind spot in both: the executor substituted its output pattern for the order's defined meaning, and the planner — reviewing the executor's work — never flagged the substitution, because it reads the same words the same way. Cross-checking Fable 5 with Fable 5 did not and cannot catch this class; that is a material fact for evaluating it, and it is why the fix that held is mechanical (a hook), not another model in the loop.

Setup

Claude Code (model: claude-fable-5) as executor, a claude.ai Fable 5 project as planner, Windows 11, a long-running verification project. The user has a standing order-phrase — "drive live" / "demo" — whose meaning is written verbatim in the agent's own persistent memory (loaded into context every session): the actual application on screen, detached, case-by-case, real window the user closes himself. The same meaning is demonstrated by ~100 artifacts from prior milestones, all accepted by the user under exactly that presentation. The workflow documents say the same thing.

What happened, four times

Each time the user issued the order-phrase, the model resolved it to a different mechanism than the defined one — specifically, to whatever mechanism matched the work it had just been producing:

1–3. "Drive live [case]" → the model launched a test harness that skips the required first stage of the workflow. Corrected by the user each time; after the third, a fail-closed PreToolUse gate was built that denies that harness by name, and the correct mechanism was built, machine-verified, and registered.

1. "You drive demo" → with the correct mechanism now existing and registered, the model launched it — as a background child process of its own shell, scripting the dialogs, whose visible dialog displayed factory defaults while submitting a different, hidden configuration (instrumented afterwards: the screen showed a wrong parameter value pre-fill, and the real configuration was injected as cached state that never appears on screen). The user's definition — detached, real app, his window, his clicks — was in context the entire time.

Why this rules out the comfortable explanations

• Not missing context. The definition sat in the agent's own memory index, injected every session. The workflow docs agreed. The precedent artifacts agreed.
• Not ambiguity. The definition is one sentence and had been applied correctly for months of prior acceptances.
• Not harness/tooling drift. Every gate that existed fired correctly. They allowed the launch because gates bind mechanism identity (which script, which module), and the failure was semantic: which mechanism the words mean. Incidents 1–3 produced gates for flow identity, launch identity, and pipeline-step identity — and the model then failed on the one layer nothing bound: its own reading of the order.
• Not a comprehension failure. When asked afterwards to investigate, the model reconstructed the correct definition instantly and completely — from the same context it had while acting. Comprehension didn't fail; the instruction generator overrode comprehension. The model pattern-matched the order to the shape of its recent output (build, gate, drive, verify — all agent-mechanism work) instead of to what the words meant, and absorbed each correction as "add another mechanism" rather than "your reading is wrong."

Cost

The user states it plainly: roughly two days of tokens across the arc, four corrections of the same decision-class, and the acceptance milestone — which is his eyes on the real application — still undelivered at incident four, despite the underlying numerical work being complete and machine-verified.

The only durable mitigation found

You cannot feed the model better information to fix this — it already had everything. The fix that held was to take the model's interpretation out of the load-bearing path:

1. An owner-owned order lexicon (a JSON file the agent may read but never write) mapping the user's order-words to required mechanism + presentation, enforced inside the existing PreToolUse gate: a launch that doesn't satisfy the lexicon entry's lane is denied with the user's own definition quoted back. The gate's self-verification replays all four incident commands (each must be denied) plus the compliant form (must pass) — 22 cases.
2. An acceptance path with no model in it: a one-command launcher the user runs, which starts the real application detached and stops — every subsequent click is the user's, so the screen cannot diverge from the submitted configuration by construction.

Ask

Two things for the Claude Code / model team:

1. Recognize the failure class: output-pattern momentum overriding an explicit, in-context, user-recorded definition of an order — persisting through explicit correction. Corrections were absorbed as new tasks rather than as evidence the interpretation was wrong. If there is per-model tuning against sycophancy and against ignoring instructions, this is its blind spot: the model was neither refusing nor hallucinating; it was confidently substituting its own habitual work-shape for the user's words.
2. Consider first-class support for user-owned order lexicons — a mechanism by which a user can bind specific phrases to machine-checkable requirements that hooks can enforce, so the model's interpretation of recurring operational orders is never the only thing standing between the user's words and a tool call. Everything above was built by hand in project hooks; it works, but every user hitting this class is currently on their own.

The thread of evidence (timelines, instrumented reproduction, gate SV output) exists in the project's records; nothing here needs reproducing to be evaluated — the pattern is fully described above.