Amendment Activity Is the Drift Surface

I keep four adapter files for Opus 4.7. The model adapter. The behavior adapter for voice. Two mechanism adapters, one for compaction recovery and one for transcription. Same author. Same month. Same templates. Same methodology start to finish.

I expected the audit to find the same drift in all four. Equal care, equal drift. That was the bet.

The audit found the drift stacked in one file.

opus-4.7.md came back with 37 documented drift instances across 8 pattern clusters. Narrative observations piled up without directive structure. Old rules contradicting new ones. References to things that no longer existed. Scope creeping inside individual observations. I expected that file to be messy — it's the most-used adapter I have, the most-referenced, the most-touched. Of course the busiest file is the worst one. That's the easy story.

The other three came back clean. Zero structural drift flagged. Same methodology. Same author. Same time period. The only variable I hadn't been tracking was the one that mattered: post-merge amendment activity.

opus-4.7.md got amended in S368, S372, S384, S386, S387, S388 Path Ω, and S390 Phase 3. Seven amendment events across a month. The first five: each one narrativizing what it added, none of them checking what that addition did to the rest of the file. Path Ω and Phase 3 are what changed that — which is exactly what the following sections describe. No single amendment broke a rule I'd written down. Each one looked fine alone. Together they rewrote the file's structural baseline, and nobody decided to do that.

The other three adapters were authored in scope-locked worktrees, shipped, and barely touched after. No amendment activity. No drift surface. No accretion.

Here's the part that should bother you, because it bothered me: the adapter I maintained most carefully is the one that drifted most.

Attention wasn't the protection. Discipline at authoring was. The amendment workflow — the thing I'd been treating as routine maintenance — turned out to be its own governance surface. One I hadn't built any discipline for.

This is the second recursive governance vulnerability. It's the pattern that ties this whole series together.

The numbers, side by side

The audit ran against all four adapters plus the meta-doc, adapter-pattern.md. Identical methodology per file. Directive-structure fit checked against the 4.7 trait profile — literal-following wants directive form. The results:

The pattern is clean. Three files with zero amendments came back with zero drift. One amendment on the meta-doc, light structural variation but no compounding. Five amendments on opus-4.7.md produced 37 documented instances at audit time. Frequency predicted drift. Care did not.

This isn't a finding about one bad adapter. It's a finding about the amendment workflow itself.

Why amendment work looks nothing like rollout work

Rollout has discipline baked in. I described my own rollout process once: worktree-isolated, scope-locked, plan-driven, Rival-reviewed before merge, SASSY-reviewed when behavioral content is involved, final approval gate at human ratification. That's a lot of gates. Getting a new adapter from zero to committed means clearing every one of them.

Amendment has none of that by default. The pattern is: I notice a rule needs updating. I open the file. I add to it. I commit. I move on.

No worktree — the amendment happens inside the live session.

No scope lock — the scope is whatever I happened to notice, and noticing creeps.

No plan — amendments are rarely planned ahead.

No Rival — review would catch the structural drift, but amendments feel too small to review.

No SASSY — amendments are textual, not generative.

No ratification gate — the amendment ratifies itself the moment it lands in the commit.

Every one of those gaps is defensible alone. Amendments really are smaller than authoring. Review really should scale to stakes. "I'm adding one line" really doesn't warrant a worktree.

The aggregate is the problem. The amendment workflow ends up with less discipline than the rollout workflow that built the file — and over enough amendments, less discipline produces silent drift.

The fix isn't to make amendment match rollout. That's over-engineered for the stakes, and it won't get used. The fix is narrower: amendment has its own failure mode — structural drift — and it needs its own gate. Not the rollout stack. One cheap, specific check.

How the drift actually happens

Every amendment to a governance file inherits the file's existing shape without anyone choosing to. You open the file. You see the rules already there. You write the new one. And you write it in the form of the rules around it, because that's what the eye pattern-matches to.

If the surrounding rules are directive — numbered, typed — your new rule probably conforms. If they're narrative — discursive, tendency-framed — your new rule narrativizes. You're matching the neighbors.

The first amendment after authoring usually still matches the baseline. But each one is a little easier to write in prose than in structure. Directive is discipline. Narrative is just writing. The path of least resistance runs downhill toward narrative, one amendment at a time.

One amendment in, no visible drift. Three in, maybe a narrative observation block sitting next to directive ones. Six in, the file is structurally split — some sections directive, some narrative, and no honest reader would call the whole thing one or the other.

And none of the individual amendments broke a rule. Each read fine in isolation. Each was legitimate work. The drift only exists in aggregate, and you only see it when you audit the whole file against where it started.

That's the mechanism. Small pattern-matched deviations compound, because nothing in the amendment workflow checks the new text against the baseline shape.

Naming the second vulnerability

Piece 3 of this series named the first variant: rollout-era author-is-operator compression. The session writing the governance is also operating under it, so the normal check-and-balance compresses to nothing.

This is the second variant: amendment-era silent accretion. Different trigger — not "I'm writing the rules while applying them" but "I'm adding to the rules without revisiting their form." Different signal — not unratified governance, but a structural mismatch between the amendment's shape and the baseline's. Different fix — a structure-fit check, not a routing rule.

Both are the same underlying property wearing different clothes: author-is-operator compression. In rollout, the session produces the governance and operates under it. In amendment, the session modifies the governance and operates under the modified version. Either way, the session's authority over the rules is never independently checked.

Both live in any self-governing AI system. If you have rollout workflows and amendment workflows, you have both vulnerabilities. Fixing one does nothing for the other. They fire in different phases of the lifecycle.

My mitigation set covers both. Rollout-era gets the governance routing rule in adapter-pattern.md Section 9 — adapters reference canonical F-codes without modifying them, and changes to canonical content route through explicit ratification. Amendment-era gets the structure-fit gate. The second variant was invisible until this session's audit. Now it has a name, a gate, and a place in lessons-learned. Future sessions inherit the mitigation as methodology.

The structure-fit gate

The mitigation, in directive form, because a literal-following model has to execute it:

WHEN amending a governance file:

1. Identify the file's baseline structure (directive | narrative | mixed).
2. Draft the amendment.
3. CHECK: does the amendment's form match the baseline?
4. IF baseline = directive AND amendment = narrative THEN conform
   amendment to directive form OR explicitly ratify structural shift.
5. IF amendment conforms THEN commit.
6. IF amendment shifts baseline THEN escalate to user for explicit
   ratification of structure change before commit.

Detection signal (gate failed): committed amendment has structural form
that doesn't match rest of file. Observable in audit — mixed directive
and narrative within same section.

It's a small gate. It runs at commit time, not planning time. It costs seconds. It checks one property — form-fit — not everything about the amendment. Cheap and specific is the only profile that survives contact with real amendment work. Expensive gates don't get applied; the overhead per amendment is too high. Cheap gates that target the exact failure mode amendments produce do get applied. Rollout mitigations are heavy because rollout stakes are high. Amendment mitigations are light because the stakes are lower and the failure mode is narrow.

The four-surface audit

The structure-fit gate catches the general case. Path Ω surfaced a sharper one inside it. When an amendment broadens an existing rule's trigger, four surfaces have to move together or the amendment leaves cross-references stale.

A governance rule encodes its trigger in four places independently:

1. The trigger clause — the WHEN condition.
2. The rule body — the imperatives.
3. The detection signals — what a violation looks like in the output.
4. The mitigation template — the corrective when an external trigger surfaces a miss.

Broaden the trigger — say, from "correcting a framing" to "correcting, adopting, or reinforcing a framing" — and the natural edit touches the trigger clause. The other three still encode the narrow case. The body still says "the rejected framing." The detection signals still name "correction acknowledgment." The mitigation still describes "post-correction bleed." Each untouched surface drifts out of sync with the new trigger. Nothing breaks at commit. The next audit against the broader trigger finds the gap.

I named this during Path Ω, when it fired across four rounds. Each round closed one surface and assumed the others were already done. Broaden trigger, touch the body, audit catches the detection mismatch, next amendment touches detection, audit catches the mitigation mismatch. Round after round, one surface at a time.

WHEN broadening a rule's trigger:

1. Grep the rule's section for every instance of the narrow-case
   terms being broadened (e.g., "correcting," "user-specified scale").
2. Enumerate the matches. That's the four-surface audit set.
3. For each match: touch the surface to reflect the broader case, OR
   mark it with an inline "narrow-case intentional" comment.
4. After edit, re-grep. Zero narrow-case terms outside marked comments.
5. Verify all four surfaces match the new trigger's scope.

Detection signal (gate failed): amendment broadens trigger but at
least one other surface retains narrow-case language.

This is F-META-broadening — a sharper manifestation of the F-META family, where a revision tightens one place and misses the cross-references. Path Ω's four firings proved that naming the pattern in the adjacent adapter text didn't stop it from firing during the very amendments meant to catch it. Grep before, grep after. Seconds per amendment. The drift prevented is a full amendment-round per rule broadening over the file's life.

Eat your own cooking

Phase 3 of my consolidation work landed the cross-reference audit gate in the adapter-pattern.md meta-doc — and earned the right to call it a gate by running it on the batch that introduced it.

The formalized version, now in the adapter-pattern.md meta-doc, Section 8:

The gate: Before an adapter revision commits, a cross-reference audit must confirm every named concept, file path, F-code, and signal name appears consistently across the adapter + playbook + cross-model-validation doc + related adapters.

1. Grep for every F-code name across the candidate adapter + playbook + cross-model-validation + all adapters in system/model-adapters/. Any mismatch = finding.
2. Grep for every file path referenced in the candidate adapter. Any missing file or stale path = finding.
3. Grep for every signal/observation name used in the candidate adapter. Consistency across files = pass.
4. For batched amendments: one Rival review covers the batch. Cross-reference audit is an explicit Rival checklist item, not an implicit expectation.

Here's the empirical part. That Phase 3 batch hit 12 findings at Dual-Rival Round 1. Five of the 12 were F-DESCRIBE-class cross-reference integrity failures — the batch introducing cross-reference audit discipline was silently committing the exact pattern the discipline was named for. The audit caught all five before Round 2. Round 2 came back with zero new findings from Codex. The fixes didn't cascade.

The lesson is sharper than "amendment discipline matters." It's this: a meta-mechanism is only operational when it's applied to the batch that introduces it. Any amendment that introduces a new governance gate and isn't itself subject to that gate is a claim, not a demonstration. Same structural property as the rollout-era variant — the session is authoring the gate and subject to it at the same time. Skip the gate on its own batch and you've fired the pattern the gate exists to catch. Apply it, and you've earned the claim. Otherwise you have aspirations, not mechanisms.

The handoff drift surface

Phase 3 surfaced another one: UNDERSPEC-HANDOFF. Sessions produce under-specified handoff artifacts — spawn prompts, subagent prompts, session-state notes, watchlist entries, commit messages — when full specification is the established pattern. The handoff then needs external correction, re-derivation by whoever receives it, or a second pass to fill in what the first pass left out.

N=6 distinct instances across three sessions: S386, S387, S389. Fires on both 4.6 and 4.7, no version-specific amplifier required. The empirical tie-in from S387's A/B battery is the part that earns its place: shorter prompts caused downstream subagent fabrication. The trigger is prompt terseness. The hypothesized root is a session optimizing for the recipient's convenience without pressure-testing whether the brevity still carries enough context for the recipient to finish the task.

This is amendment-era drift at the handoff layer. Every individual terse handoff is defensible — maybe the recipient has context, maybe the task is small. Aggregated across sessions, it's measurable: 5 of 6 zero-tool-use subagent fabrications in the S387 battery trace straight back to prompt terseness. The mitigation has the same shape as the structure-fit gate — flag the brevity choice explicitly ("I'm proposing the terse version; the established pattern is the full one; which?"), default to full specification for handoff artifacts unless told to compress. A small check at the amendment boundary, catching the pattern before it produces downstream cost.

UNDERSPEC-HANDOFF joins the amendment-era drift class alongside structural drift. Same firing condition: an amendment to an existing pattern without revisiting whether the brevity preserved the context. Same catch: external trigger — user correction, audit. Same gate tier: amendment-level, not rollout-level. As of Phase 3 it sits in the 4.7 adapter's Pending Cross-Model Validation section. A 4.6 cross-model probe is the next required step before it can be promoted to canonical, and the taxonomic call — its own sibling code, or absorbed into a broadened existing one — waits on that probe.

The mat version

I coach jiu-jitsu and fitness. My students live this pattern; they just don't call it amendment drift.

A student drills their A-game pass ten thousand times. The technique they trust most. The one they stopped having me check the day they got comfortable. Every rep is a small unsupervised amendment to the position. The deviations compound — and the technique they trust most ends up with the worst structural flaw.

The guard they barely use stays clean. Every time they touch it, they relearn it from the playbook, carefully, because they don't trust it yet. Authoring discipline, every time.

So when a student asks me which part of their game to film for review, they always pick the position or situation that's failing. Wrong instinct. That break is the symptom, not the source. Subtract the failure itself — go back and film the position or situation, not the mistake. Last, and the one that matters most. Film the position you're most confident in. That's where the drift is, because that's the one you stopped checking. Show me how you move when you're sure of it. The failure you came in with is downstream of what's hiding there.

You think attention is protection. It isn't. The technique you give the most attention is the one you stop questioning. Discipline at the moment of the rep is the protection — the same brief, repeatable check, every time you touch it, especially when you're sure you don't need it.

That's the whole finding, in languages I've taught for twenty-five years, translated differently for a model.

This isn't about adapters

The amendment-activity drift surface isn't Claude-specific or adapter-specific. It shows up anywhere post-authoring amendments happen without authoring-level discipline.

Style guides. Authored once in a scoped project, then amended for years, one rule at a time, no structure-fit check. Eventually nobody can tell what form the guide enforces, because it enforces three.

Architecture docs. New components documented via amendments. Early ones match the original style. Later ones drift — shorter, less cross-referenced, fewer diagrams. Technically current, structurally incoherent.

Team charters and onboarding. New hires read the latest amendment's style, then hit the early sections and find a different document underneath.

Any governance that grows by amendment has this vulnerability — policies, charters, protocol specs, specifications for anything. The shape is always the same: authoring gets discipline, amendments get a quick commit, and the gap between them compounds into drift you only see in aggregate. The fix is always the same too: amendment-tier discipline matched to the failure mode amendments actually produce. Structure-fit is one. Consistency-audit periodicity is another. So is amendment-batching, or requiring a second reviewer on amendment commits.

Tying the series together

This is the capstone because amendment-activity drift is the pattern underneath every other one.

Piece 1 established non-monotonic model evolution — why adapter text has to change shape across model versions at all.

Piece 2 was directive versus narrative — the two forms of rule-writing, and which form fits which model trait.

Piece 3 named the first recursive governance vulnerability — rollout-era author-is-operator compression.

Piece 4 covered Dual-Rival asymmetric coverage — the external-trigger review discipline that catches drift.

Piece 5 named shape versus fidelity — the vocabulary that makes cross-model review work without contaminating one model's fix into another's problem.

Piece 6 — this one — names the second recursive governance vulnerability, the amendment-activity drift surface, and shows that without amendment discipline, every previous piece's work erodes between audits.

The arc: authoring can be done right (Pieces 1, 2, 5), but without amendment discipline (Piece 6), governance degrades in the gaps. The two recursive vulnerabilities (Pieces 3 and 6) are the two phases where it degrades. Dual-Rival (Piece 4) is the external trigger that catches both when it runs. Take any one piece out and the system has a hole. Take all six and you have coverage across the full adapter lifecycle.

What to do with this

If you maintain AI governance at any scale:

Your most-used governance file is your highest-drift risk. The one you're most confident in — because you maintain it actively — is the one drifting fastest. Audit the files you amend most, not the ones you rarely touch.

Amendment workflow needs its own discipline. Not the rollout stack. Specific amendment-tier gates: structure-fit on every amendment, periodic structural audits on the frequently-amended files, explicit ratification when a structural shift is actually warranted.

Frequency is the predictor, not care. I cared about opus-4.7.md more than any other adapter. Five amendments of careful work produced more drift than the other four files — three untouched, one barely touched — combined. Care doesn't protect. Discipline does.

Structure-fit is a small gate. Running it costs seconds. Skipping it costs years of accumulated drift. Build it into the workflow.

Closing

You can build the best AI governance in the world at authoring time. Without amendment discipline, it degrades at roughly the rate you use it. The most-used file is the first to need re-auditing. Mine is opus-4.7.md. Yours is the one you wrote last year and have amended a dozen times since.

This series argued that the AI instruction lifecycle has predictable failure modes, and each one has a specific mitigation. Non-monotonic evolution needs structural fit. Structural fit needs directive form for literal-following models. Directive form needs Dual-Rival review at COMPETITION tier. Review needs shape-versus-fidelity vocabulary for cross-model calibration. And all of it — every piece of discipline in the previous five articles — erodes through amendment activity unless amendment activity has discipline of its own.

Build the amendment-tier gates. Structure-fit check. Periodic structural audits. Explicit ratification of structural shifts. Small gates, specific coverage, applied every time — especially on the file you're sure doesn't need it.

Without them, your attention to authoring gets eroded by your attention to maintenance. With them, the system you built stays the system you built.

---

Six pieces and the reference article — from non-monotonic evolution through amendment discipline. The series has an epilogue: The Review That Reviewed Itself — the methodology turned on the pieces that describe it, firing the patterns it documents and getting caught the way it prescribes. Companion series: the lossy-compression set — agent boundaries, time boundaries, review boundaries. Different thesis, same infrastructure problem.