@@ -426,9 +426,11 @@ hardware. It may vary across models or be tuned for throughput:
   provided routing, capacity, token dropping, and auxiliary losses are
   unchanged.
 
-For the final verification-card recipe, use no recompute when it fits;
-otherwise use the narrowest measured selective boundaries. Full recompute is
-acceptable temporarily for diagnostic bring-up, but can severely reduce
+For the final verification-card recipe, no recompute and selective recompute
+on cheap supported modules are both appropriate starting choices. Choose by
+measured memory headroom and steady-state performance; selective recompute
+does not require a no-recompute OOM first. Full recompute is acceptable
+temporarily for diagnostic bring-up, but can severely reduce
 throughput. Retain it only when target-scale measurements show no recompute
 and supported selective boundaries still fail to fit. Record memory/OOM
 evidence, boundaries tested, and steady-state performance cost in the recipe's
 
@@ -19,8 +19,8 @@ Activation recompute (activation checkpointing) trades additional forward work d
 ## Quick Decision Guide
 
 1. Confirm the pressure is real allocation, not allocator fragmentation. Compare `max_memory_allocated()` with `max_memory_reserved()` on every rank.
-2. Start final library, performance, and verification-card recipes with no recompute when the workload fits. Keep an explicit no-recompute control. Under selective granularity, `recompute_modules=[]` is valid and useful for this comparison.
-3. When no recompute does not fit, select the narrowest supported boundary from the architecture and observed peak:
+2. For final library, performance, and verification-card recipes, no recompute and selective recompute on cheap supported modules are both appropriate starting choices. Choose by measured memory headroom and steady-state performance; a no-recompute OOM is not a prerequisite for selective recompute. Keep an explicit no-recompute control when it fits. Under selective granularity, `recompute_modules=[]` is valid and useful for this comparison.
+3. For selective recompute, start with cheap supported boundaries selected from the architecture and observed peak:
    - **Standard attention:** `core_attn` is the common first candidate. It is strongest when unfused attention materializes score/probability tensors. With Transformer Engine fused or Flash Attention, compare it against `[]` because those backends already rematerialize attention internals.
    - **Multi-Latent Attention (MLA):** start with `mla_up_proj` when expanded Q/K/V projections dominate. Add `core_attn` only when the attention-core state still matters.
    - **Grouped MoE:** start with `moe_act` when the expert intermediate activation dominates; add `layernorm` when norm outputs are material. Use whole `moe` recompute only after accounting for the extra expert compute and communication it replays.
@@ -138,8 +138,8 @@ iteration 2. Time and throughput are means over iterations 11--20.
 | `moe_act` | 35.941 | 466.26 | 75.50 | -1.85% | +1.99% |
 | `layernorm`, `moe_act` | 35.949 | 506.53 | 70.27 | -1.83% | +10.79% |
 
-For this exact workload, no recompute fits and is preferred. If additional
-headroom is needed, `moe_act` is the best first tested boundary: it recovered
+For this exact workload, both no recompute and cheap selective `moe_act` are
+reasonable choices depending on the desired memory headroom. `moe_act` recovered
 nearly as much allocated memory as `mla_up_proj` for less replay cost.
 `mla_up_proj` is the next candidate if its roughly 39 MB additional reduction
 matters. Adding `mlp` to `mla_up_proj` or `layernorm` to `moe_act` did not
@@ -182,12 +182,11 @@ is used here.
 ### Cross-model conclusion
 
 These measurements do not define one ranking. Moonlight fit with an empty
-control, so no recompute is preferred; narrow `moe_act` is a candidate when
-additional headroom is needed. Nemotron required broad whole-`moe` recompute;
-historical dense Llama evidence found whole-`mlp` replay costly and lacked an
-empty control. Start with no recompute when it fits, then the narrowest boundary
-implicated by the architecture and peak, broadening only when the narrow choice
-does not pass the complete step.
+control, and cheap selective `moe_act` offered additional headroom at modest
+cost. Nemotron required broad whole-`moe` recompute; historical dense Llama
+evidence found whole-`mlp` replay costly and lacked an empty control. Start with
+no recompute or cheap selective boundaries, choose by measured memory and
+performance, and broaden only as needed to pass the complete step.
 
 ## Compatibility and Validation
 
 
@@ -72,10 +72,11 @@ The smaller Qwen3.5-style multimodal experiments reinforce the same lessons:
 
 ### Choose recompute for the final recipe
 
-For library, performance, and verification-card recipes, start with **no
-recompute when it fits**; otherwise use the narrowest supported selective
-boundaries measured to fit at target scale. Full recompute can severely reduce
-throughput. It is acceptable temporarily during memory-constrained diagnostic
+For library, performance, and verification-card recipes, **no recompute and
+selective recompute on cheap supported modules are both appropriate starting
+choices**. Choose using measured memory headroom and steady-state performance
+at target scale; selective recompute does not require a no-recompute OOM first.
+Full recompute can severely reduce throughput. It is acceptable temporarily during memory-constrained diagnostic
 bring-up, but a successful bring-up run does not justify publishing it as the
 default. Retain full recompute only when target-scale measurements show that
 no recompute and supported selective boundaries still fail to fit. Document
@@ -98,9 +99,9 @@ performance cost.
    or output-layer weights, and the final choice must respect PP/DP rank layout
    and the hardware topology.
 
-3. **Use no recompute when it fits, then measured selective recompute**: if
-   temporary full recompute was used for bring-up, test no recompute and the
-   narrowest supported selective boundaries before recommending a recipe.
+3. **Use no recompute or cheap selective recompute**: if temporary full
+   recompute was used for bring-up, evaluate these lighter choices before
+   recommending a recipe; broaden selective boundaries only as needed for fit.
    Measure memory and steady-state throughput rather than carrying the
    diagnostic setting forward.
 
@@ -140,9 +141,9 @@ Use this order so each measurement answers one question:
 2. Minimize TP while retaining enough memory for non-expert weights.
 3. Establish a stable real-data run. Temporary full recompute is allowed for
    diagnostic bring-up when memory fit is uncertain.
-4. Select the final recipe by testing no recompute first, then the narrowest
-   supported selective boundaries needed to fit at target scale. Retain full
-   recompute only under the documented exception above.
+4. Select the final recipe using no recompute or cheap supported selective
+   boundaries, measuring their memory/performance tradeoff at target scale.
+   Retain full recompute only under the documented exception above.
 5. Measure per-rank peak allocated/reserved memory and steady-state step time
    or throughput through optimizer initialization and multiple complete steps.
 6. If there is headroom, increase MBS; if TP was used for activation pressure,
@@ -163,7 +164,7 @@ fits is the baseline; it is not automatically the performance recipe.
 TP=1  CP=1  PP=1
 EP sized to the expert topology, often large
 Dispatcher: HybridEP on GB200-class systems
-Recompute: none when it fits; otherwise the narrowest measured selective boundaries
+Recompute: none or cheap supported selective modules; measure memory and throughput
 ```
 
 ### 3D-parallel GB200 path
@@ -182,7 +183,7 @@ CUDA Graph: start narrow, then widen only after the real-data path is stable
 | HybridEP on GB200 | strong default | strong default once topology is stable |
 | CUDA graphs | useful after bring-up | useful, but more scope-sensitive |
 | Freeze vision | natural fit | possible, but less often used as the headline perf path |
-| Selective recompute | when no recompute does not fit | when no recompute does not fit |
+| Cheap selective recompute | appropriate alongside no recompute | appropriate alongside no recompute |
 
 ## Pitfalls
 
 
@@ -261,9 +261,11 @@ For an MoE recipe on a fixed allocation, use this practical order:
    is a common first candidate on one 8-GPU node, and EP=32 is a common first
    candidate on a 32-GPU allocation. These are starting points, not universal
    defaults: EP shards expert weights only, not dense layers or activations.
-3. For final library, benchmark, and verification-card recipes, start with no
-   recompute when it fits; otherwise use the narrowest measured selective
-   boundaries. Full recompute is acceptable temporarily for diagnostic bring-up,
+3. For final library, benchmark, and verification-card recipes, no recompute
+   and selective recompute on cheap supported modules are both appropriate
+   starting choices. Choose by measured memory headroom and steady-state
+   performance; selective recompute does not require a no-recompute OOM first.
+   Full recompute is acceptable temporarily for diagnostic bring-up,
    but can severely reduce throughput. Retain it only when target-scale
    measurements show no recompute and supported selective boundaries still fail
    to fit; document memory/OOM evidence and steady-state performance cost. For