The Adapter Pattern: Why Your AI Instructions Age Out

The rules I wrote for 4.5 broke when 4.6 launched. The rules I rewrote for 4.6 broke when 4.7 launched. Same instruction stack. Same divisions. Same problems. Different model, different shape.

That's the part nobody tells you about AI instructions. They don't age out the way training data does. The model moves underneath you.

I run the whole stack on a set of custom Claude instructions — thousands of lines across CLAUDE.md files, agents, skills, protocols. When 4.5 was the default, the instructions read like numbered orders. STOP. Classify each finding. Spawn the domain expert. Present to user. Only then begin edits. The model followed them.

4.6 launched. Same rules. They started to backfire. 4.6 read MUST and CRITICAL like sacred text — would lock onto whichever rule had the loudest emphasis and quietly demote everything else. So I rewrote in softer prose. Consider the findings. Tend toward classification. When in doubt, spawn the expert. 4.6 followed that. The system held.

Then 4.7 launched.

The soft prose started producing drift. Not hallucinations, not quality drops — something quieter. The model would read a narrative instruction and interpret it instead of executing it. And interpretation, at scale, is where drift lives. Across 37 incidents, the same pattern: the rules I'd written for 4.6 were the exact shape 4.7 couldn't follow.

The diagnostic took about a minute. 4.7's public docs said the first half plainly: more literal instruction following. The reversion-toward-4.5 read is mine — that's what I saw when I lined the trait profiles up against each other. The fix was the same minute's work. Rewrite in 4.5's directive style. Numbered steps. Typed enums. Explicit STOP gates. Same rules. Different shape.

Behavior stabilized. A second pass closed the gaps the first pass missed.

That's the story of one workstation. The interesting part isn't that I had to rewrite. The interesting part is why — and what it says about how these systems work when you're not paying attention. What's underneath has three properties that aren't usually named together: non-monotonic model evolution (model versions don't improve in a straight line — they revert, extend, and break in patterns), structural fit (instruction text style must match the target model's trait profile, not just its topic coverage), and recursive governance vulnerability (the session writing the rules is the session operating under them).

Put them together and you get a predictable lifecycle for AI instruction code. Which means you can plan for it.

Non-monotonic model evolution

The industry assumption is that model versions get better in a straight line. GPT-3 → GPT-4 → GPT-5 is supposed to be steps on a staircase, each one more capable, each one more obedient, each one more reliable. The rules you wrote for the earlier version should still work on the later one — better, even.

That's not what happens. At least not on Anthropic's Opus 4 line.

I ran a twelve-axis comparison across 4.5 → 4.6 → 4.7 during Phase 1 of my rollout work.

The numbers in this piece — the twelve-axis breakdown, the 37-incident inventory, the Round-1/Round-2 finding counts, the 73.5% first-pass rate — come from my own rollout instrumentation across one operator's stack. Not a published dataset; not a benchmark. One workstation, instrumented.

Here's how the axes broke down:

• 4 axes reverted toward 4.5 (procedural adherence, tool-call calibration, subagent spawning, emphatic tone handling)
• 2 axes extended 4.6's improvements (response length calibration, progress update cadence)
• 4 axes are net-new capabilities (effort level differentiation, steering phrases, vision, cyber safeguards)
• 2 axes are breaking paradigm shifts (adaptive-only thinking, tokenizer expansion)

A third of the behavioral surface reverted. That's not a minority you can ignore.

What it means in practice: 4.6-era rules that mitigated 4.6-specific drifts are now miscalibrated against 4.7, because 4.7 doesn't have those drifts. My 4.6 adapter had an explicit rule — "Avoid MUST, CRITICAL, MANDATORY. This model overtriggers on emphatic language." That was correct 4.6 discipline. On 4.7, emphatic markers work as written with no hierarchy inversion. The rule is dead weight at best, miscalibration at worst.

Anthropic's own guidance says the same thing. The official prompting best-practices docs put it directly: "Claude Opus 4.7 interprets prompts more literally and explicitly than Claude Opus 4.6, particularly at lower effort levels. It will not silently generalize an instruction from one item to another, and it will not infer requests you didn't make." Boris Cherny, Claude Code's creator, posted on release day: "Opus 4.7 feels more intelligent, agentic, and precise than 4.6. It took a few days for me to learn how to work with it effectively, to fully take advantage of its new capabilities." Claude Code's lead had to recalibrate too.

The arc isn't "newer is more capable, and more obedient." The arc is "newer is more capable, but its obedience is shaped differently."

For anyone maintaining an instruction stack: your stack's fitness depends on which axis of the model's trait profile changed. Rules calibrated to the previous shape need per-axis re-evaluation when the model shifts. Not "more tolerance now" — sometimes less tolerance, sometimes inverted rules, sometimes new rules for new capabilities.

The inversion: when last model's defense becomes next model's failure

The clearest example of non-monotonic evolution is what I've started calling the inversion. It plays out on emphatic-language handling between 4.6 and 4.7.

Here's the 5-step Rival Classification Gate from my 4.5 adapter file (written February 2026, my first Claude Code adapter):

After Codex returns findings with [BLOCKER] or [WATCH]:

1. STOP. Next output is a CLASSIFICATION TABLE, not an edit.
2. Classify each finding: ALREADY ADDRESSED / RESTATEMENT / PARTIAL / NEW
3. For NEW/PARTIAL: spawn domain expert via Task tool
4. Present TEAM RECOMMENDATION to George
5. Only then begin edits

Self-check: "Am I Safe... given I haven't classified findings with the team?"

If classification not done → STOP. You are about to repeat S181/S208/S220.

Directive. Numbered steps. Typed enum (four values, no escape hatch). Explicit STOP as a verb. Conditional escape with an action arrow. Concrete evidence cited for what goes wrong if it's violated.

4.5 executed it as written. The rule held.

4.6 launched. Same rule, kept verbatim in the 4.6 adapter — and it started producing hierarchy inversions. 4.6 treated STOP as sacred. Would stop, refuse adjacent work, collapse the rest of the instruction stack into secondary status. The Classification Gate worked, but the rest of the adapter got distorted every time the Gate fired. You couldn't write emphatic language in one rule without affecting how the model read your other rules.

So I rewrote. The 4.6 adapter softened emphatic language across the board. State requirements directly: "Do X" not "You MUST do X." Rules became narrative instead of directive. The Classification Gate became something like "Consider the findings and classify them. Work with the team on new or partial ones. Ensure findings are classified before editing."

On 4.6, that narrative form ran fine. The over-absolutization risk went away. The rest of the adapter stayed in balanced priority. The system held.

4.7 launched with reversion toward 4.5's literal-following trait. The defensive narrative form that was correct for 4.6 became the failure surface where 4.7 drifts. Narrative rules get interpreted by a literal-following model. Sounds contradictory. It's not. The model reads "consider classifying" and decides what "consider" means, what "classifying" looks like, whether to actually do it or just acknowledge the suggestion. Every interpretive opening is a drift surface.

Across 37 incidents, the same pattern: my 4.6 narrative rules got interpreted into drift on 4.7. Sometimes a small vocabulary extension. Sometimes scope creep. Sometimes a skipped step.

The inversion, in one sentence: the defensive rule written for one model's failure mode becomes the failure surface for the next model's trait profile. The 4.6 defensive stance — narrative prose to avoid over-absolutization — is now the 4.7 failure mode, because narrative creates interpretation drift on a literal-following model.

The fix: rewrite back toward 4.5's directive form. Numbered imperatives. Typed enums. Explicit STOP gates. External-trigger-activated mitigations. Same rules. Different shape.

Behavior stabilized. On the 34 directive-applicable instances from the 37-incident inventory — three were structural findings outside the strict PASS/FAIL gate — the first pass showed 73.5% coverage. Nine slipped through. A second pass closed the gaps. Strict pass rate: 100%.

Behavior, Mechanism, Meta: three adapter classes

The adapter pattern — as a tool for absorbing model variance, not the Gang-of-Four interface pattern — started as two classes. Behavior adapters absorb model variance — per-model, per-methodology. Mechanism adapters absorb Claude Code version variance — transcription format, compaction signals. Two classes, three directories. For six months that framing held.

Phase 3 of my consolidation work (April 24, 2026) added a third class. Meta-adapters absorb variance in how infrastructure and delegation docs reference per-model content. The test is mechanical: if a doc names per-model content by path or filename rather than embedding the model-specific rules inline, it's a meta-adapter. Grep for model identifiers; if the doc points to per-model content as paths or names instead of embedding it, you've got one.

Two current instances, with different governance treatment:

• adapter-pattern.md (the meta-doc itself) — flat COMPETITION tier for all edits.
• docs/worktree-spawn-prompts.md — two-tier: template-level edits are COMPETITION, individual entry additions are DRILLING.

The two-tier distinction matters operationally. Infrastructure docs whose entry-level use is high-frequency routine activity earn DRILLING-tier relief at the entry level while keeping COMPETITION at the template level. Governance docs whose entire surface is load-bearing — CLAUDE.md, PROTOCOLS.md — fit the meta-adapter definition mechanically but don't earn the relief. They stay flat COMPETITION. The class definition is broad. The treatment is narrow.

This is the architectural symmetry the two-class framing was missing. Model variance gets the Behavior class. CC version variance gets the Mechanism class. Infrastructure-reference variance gets the Meta class. Three axes of upstream change. Three adapter classes. Three governance surfaces.

Operationally closed vs statically pinned

One concrete case put pin architecture under empirical pressure. Phase 5 of my rollout (April 23, 2026) ratified a production default switch to Opus 4.7. The planned pin architecture was static — three settings plus an explicit model field in settings.json, closing all three auto-upgrade vectors at config-load time. That was the S367 thesis: four settings for three vectors.

In practice, the model field wouldn't stay put. One session, the field auto-reverted from 4.7[1m] back to 4.6[1m] between runs with no known trigger. Another session, the field said 4.6[1m] while the active runtime was on 4.7. The env var (ANTHROPIC_DEFAULT_OPUS_MODEL) stayed stable across the same window. Asymmetric: env stable, field unstable.

The replacement: operationally closed, not statically pinned. Three stable settings (env var + availableModels allowlist + effortLevel) plus an absent model field. Removing the field removed the drift surface. A per-session /model + /context runtime check catches any upstream shift. Config-load guarantees give way to runtime verification. The system becomes closed operationally — through discipline at every session start — instead of closed structurally through config alone.

The reframe generalizes. Pin architectures have two forms. Static: close the vector at config time, trust the config stays put. Operational: close the vector at runtime, trust the discipline stays applied. Empirical evidence can force a shift from one to the other.

My "four settings for three vectors" thesis was structurally correct but empirically incomplete. The model field was a drift surface under env-vs-field tension. Removing it and adding a runtime verification step closed the vector more reliably than the original static pin did.

For adapter authors: document which form is active. If your evidence supports the static form, use it. If the evidence exposes a drift surface, the operational form is the honest reframe. Don't pretend a config-only pin closes a vector when empirical data says it doesn't.

Structural fit

That's one case. The principle that runs underneath it: adapter text style must match the target model's trait profile structurally, not just topically. Not newer-is-better. Not backwards-is-better. Fit-is-better — and fit changes per model.

Call it the structural fit principle. Two parts.

Principle 1 — Initial authoring. When you write instruction text for an AI model, the structure of the text must match how the model processes instructions. Literal-following models (4.5, 4.7) need directive structure: typed enums, numbered imperatives, explicit STOP commands, observable detection signals. Over-absolutizing models (4.6) need narrative structure that doesn't let one emphatic directive hijack the rest of the file.

If you write the wrong structure, your instructions don't fail by being wrong. They fail by being processed differently than you meant. Every rule has interpretive openings. Every opening is a drift surface.

Principle 2 — Amendment lifecycle. Every post-merge amendment to an instruction file needs a structure-fit check. Does the new rule's form match the existing file's baseline? If yes, the amendment is structurally clean. If no, either conform the amendment to the baseline or explicitly ratify the structural shift. Silent structural drift through amendment accretion is the hazard I cover in Piece 6 of this series.

The second principle is what Phase 2 of my audit surfaced. I'd been maintaining four 4.7-era adapter files. I expected proportional drift across all four. What I actually found: drift concentrated almost entirely in the one file that received the most post-merge amendments (opus-4.7.md). The other three (sassy-voice.md, compaction-recovery.md, transcription.md) — authored during the same rollout in scope-locked worktrees, barely touched after — stayed clean.

Amendment activity is the drift surface. Initial authoring wasn't the problem. Maintenance was.

Eat own cooking — empirical validation (Phase 3, April 24, 2026). The structure-fit check that Principle 2 prescribes was added as a canonical lifecycle step during Phase 3 of my consolidation work. The batch introducing it included 11 amendments across 8 governance files. Before Round 2 of the Dual-Rival review, I applied the newly-introduced cross-reference audit to the batch itself — grep every F-code name, every §-anchor, every file path, every Item-to-Item cross-reference across the amendment set.

The audit caught 5 of the 12 Round 1 findings, all in the F-DESCRIBE class — describes a reference without verifying the referent. Exactly the pattern the amendment was introducing discipline against. The batch introducing the discipline was silently committing the pattern it was named for. Applying the discipline to the batch caught them pre-Round-2. Round 2 then returned zero new findings from Codex — the cleanest possible signal that the fixes didn't cascade.

The generalization: any amendment introducing a new governance gate must be subject to that gate before it commits. Otherwise the mitigation is a claim, not a demonstration.

The recursive governance vulnerability

Here's where it gets weird.

The pattern I've been describing — narrative rules getting interpreted on 4.7 — I discovered during a session where I was documenting the pattern. The session writing "SASSY vocabulary drift is a failure mode; here's the rule for how to avoid it" was, in adjacent turns, exhibiting SASSY vocabulary drift three separate times.

That's not a coincidence. That's the structural property I've named the recursive governance vulnerability: the session writing the rules is also the session operating under them, and author-operator compression breaks ratification as a check.

Two variants.

Rollout-era variant. During methodology production work — rollouts, adapter creation, governance edits — the session producing new rules is also the session that will operate under them. The normal check-and-balance, session proposes, user ratifies, compresses because the session has unusual authority over the governance it's writing. Rules slide in through ordinary commits without explicit ratification. My S367–S384 adapter rollout produced three governance drift instances of this type.

Amendment-era variant. Every post-merge amendment to an existing governance file inherits the file's structure implicitly. "I'm just adding one rule" doesn't trigger a structure-fit review. Over time, amendments narrativize silently and the file's structural baseline drifts. My opus-4.7.md accrued 37 drift instances through repeated amendment events over about a month.

Both variants share a property worth naming: documentation alone does not inoculate. You can document the pattern, name the detection signal, write the mitigation rule — and fire the pattern in the very next output emitting it. Naming something doesn't stop you from doing it when you're inside the situation that produces it.

The mitigation is external-trigger-activated gates. Internal self-detection isn't reliable; the session is inside the pattern. External trigger — user pushback, audit finding, Rival review — is what actually fires the gate and corrects the drift.

That's why the directive rule template I'm using for 4.7 has an explicit shape. Every rule carries a WHEN trigger, numbered imperatives, typed enums, observable detection signals, and a mitigation that names what the session does when an external trigger surfaces the gate's failure after the fact. The rule doesn't pretend internal gates work. It documents what happens when external triggers fire.

Case study: 8-cluster drift audit

S386 and S387 of my rollout work produced the concrete case study. I'll summarize it here. Pieces 2–6 go into each cluster in detail.

The audit inventoried 37 drift instances. Clustered into 8 pattern families. (Two more observations — INITIAL-SCOPE and PREMISE-CHECK — got installed in a follow-up pass after the first round surfaced gaps the original 8 hadn't covered.)

1. Frame-Check Gate failure — session accepts load-bearing framings (cost models, scale decisions, scope definitions) without checking the premise.
2. VOCAB-DRIFT — silent extension of canonical triage vocabulary. MODIFY dropped, ESCALATE broadened beyond scope, YOUR CALL invented.
3. HEDGE-PATTERN — binary questions get "partially X, partially Y" answers; recommendation questions get A/B/C menus instead of commitments.
4. N=1 over-inference — architectural claims constructed from single data points; reversed at N=10.
5. PERSIST-PATTERN — post-correction bleed-through. Corrections acknowledged abstractly but concrete instances remain.
6. Scope-drift during remediation — the audit itself scope-crept from "fix 3 issues" to "comprehensively overhaul the F-code catalog."
7. Minimization reflex — technical-sufficiency arguments deployed against a user's explicit rigor specifications.
8. Named-chain reading gate violation — spawning agents from memory instead of reading the chain definition.

Each cluster got a directive-structured amendment to the canonical adapter files. Same template every time: WHEN trigger, numbered imperatives, typed enums, observable detection signals, external-trigger-activated mitigation, evidence cross-reference.

The adapter file grew from 297 to 451 lines as a result. That's a feature, not a defect. The previous meta-doc framed it correctly: "Adapter files are a trajectory record, not a delta log." The adapter captures everything you've learned against the model over time. More exposure produces more patterns documented. Shrinking the file by deleting patterns isn't cleanup. It's forgetting.

The maintenance playbook

If you maintain an instruction stack against Anthropic's Opus 4 line, here's the playbook.

1. Classify your rules by structure. Every rule is either directive (numbered imperatives, typed enums, explicit STOP) or narrative (discursive prose, tendency framings, "consider X"). Tag each one.

2. Match structure to target model. If you're on 4.5 or 4.7 (literal-following), directive wins. If you're on 4.6 (over-absolutizing), narrative wins. If you're cross-model, write directive as the primary form with per-model narrative overrides where 4.6-specific drift requires it.

3. Rewrite mismatches. Rules in the wrong form for the target model are drift surfaces. Rewrite them. It's not a stylistic preference. It's structural fit against how the model actually processes instructions.

4. Gate amendments against baseline structure. Every amendment to an instruction file gets a check: "Does this amendment's form match the baseline file's form?" If no, conform it or explicitly ratify the shift.

5. Accept external-trigger-activated mitigation. Self-detection gates aren't reliable when the session is inside the pattern. User review, audit findings, Rival review — those are the activation triggers that work. Build your process around external triggers firing the gates. Don't build it around the session self-catching.

The pattern applies to plans, too

While I was scaffolding the Phase 5 rollout plan on April 16, I wrote step 5.30 as "Commit settings.json change to git." A week later, when I went to execute that step, I discovered settings.json is gitignored at system/.gitignore:87. The file literally cannot enter git history. The plan's own rollback procedure used file-based restore — which means the gitignore was intentional design, and the plan-step's wording was contradicting the plan's own rollback.

Plan-author me and plan-executor me were the same person, one week apart. The rule that made sense at authoring didn't survive contact at execution.

The adapter pattern doesn't only apply to model rules. It applies to any rule written by one version of an evolving system for another version of that same system to follow. Models evolve. Plans evolve. People evolve. The mechanism is the same.

---

If your AI instruction stack is drifting in ways that don't map to "the model got worse," you're looking at structural fit. Am I Safe? Beyond the Mat covers the adjacent diagnostic pattern — same principle, different surface.

I run this kind of diagnostic across everything I do — same principle, different stacks. The Practice has a specific protocol for it, but that's a different conversation.

---

The instructions you wrote for last year's model aren't wrong. They were right for the trait profile you were working against. The model moved. The trait profile moved with it. Your instructions have to move too.

Which of your rules were written for a model that doesn't exist anymore?

---

This is Piece 1 of 6 in the Opus 4.7 content series. Piece 2 — directive vs narrative as a structural principle. Piece 3 — the recursive governance vulnerability, rollout-era and amendment-era variants. Piece 4 — Dual-Rival asymmetric coverage. Piece 5 — shape vs fidelity, the vocabulary that makes cross-model review work. Piece 6 — amendment drift surface (capstone).