From a696b49e2a5baca36834ec5fbd384fd6c9e8f464 Mon Sep 17 00:00:00 2001
From: Vuong Hoang <vh@phasefinal.com>
Date: Tue, 25 Aug 2026 08:46:59 -0700
Subject: [PATCH] docs(training-playbook): merging a tune back toward stock can
 UNDO an abliteration
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

§3.12. brokkr-smithy-dev caught and retracted his own recommendation mid-thread;
recording it before it reads back later as advice.

A common remedy for an overfit tune is a partial merge back toward the base to
recover general capability. The published recipes that recommend it merge into
the STOCK instruct checkpoint. On an abliterated base, following that literally
re-introduces the exact refusal directions the abliteration was run to remove —
and it is silent, because the merged model looks healthier on general benchmarks
while the property the seat exists for quietly returns.

Rule: any merge-back targets the SAME base the LoRA was trained against, never
the upstream stock weights however similar the name.

The wider lesson is about recipe-card provenance. Community cards are
per-checkpoint artifacts and do not transfer across dense-vs-MoE,
stock-vs-abliterated, or size variants. The worked example: a recommendation
carried from a card for a DENSE STOCK 31B onto a MoE ABLITERATED 26B-A4B on the
strength of a shared family name. The overfitting warning on that card happened
to come from the right architecture; the pipeline, reward stacks and merge-back
came from the wrong one. Same family, three axes apart.

So: before quoting a recipe card at a decision, state which checkpoint it was
written for and which axes differ. "Same family" is not an answer.
---
 docs/pfi/training-throughput-playbook.md | 33 ++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/docs/pfi/training-throughput-playbook.md b/docs/pfi/training-throughput-playbook.md
index c96ff58..76ce5bb 100644
--- a/docs/pfi/training-throughput-playbook.md
+++ b/docs/pfi/training-throughput-playbook.md
@@ -372,6 +372,39 @@ means flash AND cuDNN are both reachable and §3.1/§3.3 simply do not apply.
 Mixed head dims plus a sliding window — Gemma-4's shape — is what forces dense
 O(n²) attention on Ampere-generation kernels and costs 65% of the step.
 
+## 3.12 ⭐⭐ Merging a tune "back toward the base" can UNDO an abliteration
+
+A common community remedy for an overfit tune is a partial merge back toward
+the base — 50/50 or similar — to recover general capability. **On an
+abliterated base that remedy is an undo, not a heal, and it is silent.**
+
+The published recipes that recommend it merge back into the **stock instruct**
+checkpoint (e.g. `google/gemma-4-*-it`). If you follow them literally on a
+project whose base was abliterated, you re-introduce exactly the refusal
+directions the abliteration was run to remove. The tune still looks "healthier"
+on general benchmarks while the property the seat exists for quietly returns.
+
+**Rule: any merge-back must target the SAME base the LoRA was trained against.**
+Never the upstream stock weights, however similar the name.
+
+⚠ **The generalisation is wider than merge-back.** Community recipe cards are
+per-checkpoint artifacts and their findings do not transfer across:
+
+- **dense vs MoE** — different training dynamics, different memory profile,
+  different everything
+- **stock vs abliterated/uncensored** — different alignment surface
+- **size variants of the same family** — different optima
+
+Real 2026-08-25 example: a recommendation was carried across from a recipe card
+for a **dense, stock** 31B onto a **MoE, abliterated** 26B-A4B, on the strength
+of the shared model family name. The *overfitting warning* on that card came
+from the right architecture; the *five-stage pipeline, reward stacks and
+merge-back* came from the wrong one. Same family, three axes apart.
+
+**Before quoting any recipe card at a decision, state which checkpoint it was
+written for and which axes differ from yours.** If the answer is "same family"
+that is not an answer.
+
 ## 4. Panel / consult discipline for perf work
 
 Perf investigations are unusually good at generating confident wrong answers,