@@ -156,8 +156,10 @@ recipe exists for that hardware, including one explicitly marked **early,
 unoptimized**. Its item status states whether the card's benchmark run has been
 verified; an `unverified` leaf still records the existence of the recipe.
 Existence or functional verification alone does not justify a tuned/optimized
-claim: require measured performance meeting the readiness guidance below and
-preserve any early, unoptimized label in the summary.
+claim: require workload-appropriate measured performance and preserve any
+early, unoptimized label in both the summary and the affected item's
+`expected_result` so generated pages display it. The library-pretraining
+readiness targets below are not benchmark-recipe acceptance thresholds.
 If the card has no concrete performance leaf,
 start `summary` with this exact disclaimer before the functional-support
 summary:
@@ -435,9 +437,12 @@ 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
+Retain it only when target-scale measurements show lighter choices still fail
+to fit, or matched runs show better end-to-end throughput with full recompute,
+for example through larger MBS or lower TP. Keep the workload, GBS, and
+convergence settings fixed; validate recipe-owned MBS/layout changes in the
+recipe rather than overriding batch size in the card. Record memory evidence,
+boundaries/layouts tested, and steady-state performance in the recipe's
 supporting record; keep public card metrics standalone as required below.
 
 Treat micro batch size and gradient-accumulation layout as execution
@@ -825,12 +830,16 @@ Optionally record `peak_allocated_memory_gib` and
 `peak_reserved_memory_gib`. They are required on verified `pretrain_fsdp`
 leaves, including every verified precision variant.
 
-For any new recipe used by a card, apply the
-[performance-readiness guidance](../nemo-mbridge-recipe-recommender/SKILL.md#performance-readiness-for-new-recipes):
-aim for roughly 200 model TFLOP/s/GPU on H100 or 400 on GB200. Use the measured
-steady-state training metrics for the intended workload. If performance is
-severely below the target, withhold the recipe or mark it **early, unoptimized**
-in the recipe, card summary, and PR, with its measured performance and limits.
+For a new **pretraining library recipe** used by a card's `pretrain` item,
+apply the [performance-readiness guidance](../nemo-mbridge-recipe-recommender/SKILL.md#performance-readiness-for-new-recipes):
+for BF16, aim for roughly 200 model TFLOP/s/GPU on H100 or 400 on GB200 using
+steady-state metrics from the intended library workload. SFT, PEFT, and
+long-context SFT are excluded. A `pretrain_performance` benchmark result does
+not satisfy this library-recipe requirement. For other hardware/precisions,
+use a workload-matched measured target as described in that guidance.
+If performance is severely below the target, withhold the library recipe or
+mark it **early, unoptimized** in the recipe, card summary, affected `pretrain`
+item's `expected_result`, and PR, with its measured performance and limits.
 Functional verification alone does not establish that a recipe is optimized.
 
 Record raw metrics for each run only. Do not store comparison payloads,
 
@@ -26,7 +26,7 @@ Activation recompute (activation checkpointing) trades additional forward work d
    - **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.
    - **Dense FFN:** `mlp` can save the whole dense-MLP activation region, but it usually costs more compute than a narrow output-discard boundary.
 4. Change one label at a time. Record per-rank allocated/reserved peaks plus steady-state step time or throughput; do not infer a global module ranking from one recipe.
-5. Full-layer recompute is allowed temporarily for diagnostic bring-up. Retain it in a final recipe only when target-scale measurements show that no recompute and supported selective boundaries still fail to fit; document the memory/OOM evidence, boundaries tested, and steady-state performance cost. Full recompute can severely reduce throughput and must not become the default from a bring-up success alone.
+5. Full-layer recompute is allowed temporarily for diagnostic bring-up. Retain it in a final recipe only when target-scale measurements show that no recompute and supported selective boundaries still fail to fit, or matched runs show better end-to-end throughput with full recompute (for example, by enabling larger MBS or lower TP). Document the memory/OOM evidence, boundaries and layouts tested, and steady-state performance of the alternatives. Full recompute can severely reduce throughput and must not become the default from a bring-up success alone.
 6. Treat CUDA graphs, FP8, context-parallel communication, and overlap features as compatibility constraints, not afterthoughts.
 
 Megatron Core's `cpu_offloading=True` is an alternative when PCIe/NVLink transfer overhead is preferable to replayed compute. It cannot be combined with activation recompute and is not compatible with pipeline parallelism greater than one.
@@ -108,7 +108,14 @@ For every candidate, capture:
 - steady-state step time or throughput after warmup;
 - a short convergence or numerical-sanity check appropriate to the task.
 
-Use a matched no-recompute control and change one recompute choice at a time. Peak memory from different jobs, backends, or parallel layouts is not a module-ranking benchmark.
+Use a matched no-recompute control when it fits and change one recompute choice
+at a time to isolate its effect. For a throughput-driven full-recompute choice,
+also compare viable no-recompute/selective layouts with the full-recompute
+layout, including any larger MBS or lower TP it enables. Keep hardware,
+workload, precision, GBS, and convergence settings fixed; record all execution
+changes and check loss. Compare useful tokens/s/GPU or complete step time,
+not replayed FLOPs. Such a layout comparison supports the final recipe choice,
+not a ranking of individual modules or checkpoint boundaries.
 
 Do not call a candidate successful merely because it advances farther than the
 control. Run through optimizer-state initialization and multiple steady-state
@@ -186,7 +193,8 @@ 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.
+performance, and broaden only when measured capacity or end-to-end throughput
+benefits justify the replay cost.
 
 ## Compatibility and Validation
 
 
@@ -78,21 +78,26 @@ 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
-the per-rank memory peaks/OOM evidence, boundaries tested, and steady-state
-performance cost.
+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, or matched runs show better end-to-end throughput
+with full recompute, for example through larger MBS or lower TP. Keep the
+workload, GBS, and convergence settings fixed. Document layout changes,
+per-rank memory peaks/OOM evidence, boundaries tested, and steady-state
+performance for the alternatives tested.
 
 ### Check performance before publishing
 
-Every new recipe needs measured steady-state performance on its intended
-workload and allocation: aim for roughly **200 model TFLOP/s/GPU on H100** or
-**400 on GB200**. For VLMs, use realistic multimodal input. If performance is
-severely below these approximate targets, withhold the recipe or clearly mark
-it **early, unoptimized** in the recipe and its public documentation/card and
-PR. Follow the [recipe publication guidance](../nemo-mbridge-recipe-recommender/SKILL.md#performance-readiness-for-new-recipes)
-for the measurement details; a successful full-recompute bring-up does not
-waive this requirement.
+Every new **pretraining library recipe** needs measured steady-state
+performance on its intended workload and allocation. For BF16, aim for roughly
+**200 model TFLOP/s/GPU on H100** or **400 on GB200**. For VLMs, use realistic
+multimodal input. These targets assess the base library recipe, not a
+`perf_recipes` benchmark; SFT/PEFT and long-context SFT are excluded. If
+performance is severely below the target, withhold the recipe or clearly mark
+it **early, unoptimized** in the recipe, public documentation/card, and PR.
+Follow the [recipe publication guidance](../nemo-mbridge-recipe-recommender/SKILL.md#performance-readiness-for-new-recipes)
+for other hardware/precisions and visible card labels. A successful
+full-recompute bring-up does not waive this requirement.
 
 ## Key Tuning Knobs
 
@@ -175,7 +180,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 or cheap supported selective modules; measure memory and throughput
+Recompute: none or cheap selective by default; full only with measured fit/throughput justification
 ```
 
 ### 3D-parallel GB200 path
 
@@ -3,7 +3,11 @@ validated_on: "2026-08-25"
 summary: >
   Training strategies for MoE vision-language models (VLMs), comparing FSDP
   vs 3D Parallel approaches. Backed by empirical data from Qwen3-VL 235B
-  and Qwen3.5-35B multimodal experiments on GB200 and B200.
+  and Qwen3.5-35B multimodal experiments on GB200 and B200. The best_configs
+  below are historical measured configurations, not default recommendations.
+  Retain full recompute only with target-scale fit evidence or a matched
+  throughput advantage over viable no-recompute/selective layouts; the
+  historical rows alone do not establish that comparison.
 
 validation_status:
   qwen3_vl_fsdp_gb200:
@@ -26,8 +30,9 @@ training_dimensions:
     effect: "FSDP shards more aggressively; 3D Parallel often needs recompute"
     confidence: medium
     rationale: >
-      3D Parallel with real vision data often needs full recompute for initial
-      fit, then should be retested with supported selective modules.
+      Full recompute can help diagnostic bring-up. For final recipes, measure
+      no recompute or cheap selective modules and retain full recompute only
+      for demonstrated capacity need or a matched end-to-end throughput gain.
   scale:
     effect: "Both approaches tested at 64–128 GPUs"
     confidence: medium
 
@@ -44,18 +44,24 @@ index details:
 
 ## Performance Readiness for New Recipes
 
-Before publishing any new library, performance, or verification-card training
-recipe, measure steady-state model TFLOP/s/GPU on its intended workload and
-GPU allocation. Aim for roughly **200 TFLOP/s/GPU on H100** and **400
-TFLOP/s/GPU on GB200**. These are approximate readiness targets, not exact
-pass/fail cutoffs; completing a run alone does not establish decent performance.
+Before publishing a new **pretraining library recipe** under
+`src/megatron/bridge/recipes/`, measure steady-state model TFLOP/s/GPU on its
+intended workload and GPU allocation. For BF16, aim for roughly **200
+TFLOP/s/GPU on H100** and **400 TFLOP/s/GPU on GB200**. These are approximate
+readiness targets, not exact pass/fail cutoffs. This requirement excludes SFT,
+PEFT, and long-context SFT; it assesses the base pretraining library recipe,
+not a `perf_recipes` benchmark or its result. For other precisions or hardware
+such as B200/GB300, establish a workload-matched measured target rather than
+silently reusing the BF16 H100/GB200 numbers.
 
 If measured performance is severely below the target, either withhold the
 recipe until it is improved or clearly label it **early, unoptimized** in the
 recipe docstring, accompanying public documentation/card, and PR description.
 Record the measured throughput, hardware, precision, workload, and GPU layout
-alongside the limitation. Do not present it as a tuned recommendation or change
-the intended training workload or convergence settings merely to meet a target.
+alongside the limitation. In a card, include the label in both the summary and
+the affected training item's `expected_result` so generated pages display it.
+Do not present it as a tuned recommendation or change the intended training
+workload or convergence settings merely to meet a target.
 
 ## Configuration Layers and Change Control
 
@@ -282,8 +288,11 @@ For an MoE recipe on a fixed allocation, use this practical order:
    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
+   measurements show that lighter choices still fail to fit, or matched runs
+   show better end-to-end throughput with full recompute (for example, by
+   enabling larger MBS or lower TP). Keep the workload, GBS, and convergence
+   settings fixed; document layout changes, memory evidence, and steady-state
+   performance for the alternatives tested. For
    Qwen3.5 GDN layers, verify `gdn_norm_out` on the exact Megatron Core revision
    instead of assuming `core_attn` covers the GDN peak.
 4. After a stable baseline completes optimizer initialization and several
 
@@ -20,12 +20,12 @@
     "question": "Use the nemo-mbridge-recipe-recommender skill. Give me a rule-of-thumb tuning loop for a Qwen MoE recipe on 8 versus 32 GPUs. Cover TP, EP, selective versus full recompute including Qwen3.5 GDN, HybridEP versus alltoall on NVL8 BF16, and what to do after the first config fits.",
     "expected_skill": "nemo-mbridge-recipe-recommender",
     "expected_script": null,
-    "ground_truth": "The answer should use the lowest legal TP that still fits dense state and prefer recompute over raising TP solely for activation memory. It should use the largest legal EP supported by expert divisibility and both parallel meshes, with EP8 on one 8-GPU node and EP32 on 32 GPUs described as starting candidates rather than universal defaults. It must state that EP shards expert weights only, so EP8 can still require full recompute. It should prefer architecture-specific selective recompute; standard-attention Qwen can start with core_attn, while Qwen3.5 GDN needs the exact revision's gdn_norm_out boundary to be tested and can fall back to full recompute when the complete optimizer step still does not fit. It should keep alltoall as the correctness baseline and treat HybridEP as a matched candidate because NVL8 BF16 results can be close. After the run fits, it should inspect W&B memory and confirm every rank's peak allocated and reserved memory in runtime logs because rank 0 can miss the hot EP or PP rank, then A/B one lower-TP step or higher MBS while keeping GBS and optimizer boundaries fixed. Acceptance requires improved end-to-end tokens/s/GPU or step time, healthy loss, no skipped or NaN iterations, and memory margin for transients.",
+    "ground_truth": "The answer should use the lowest legal TP that still fits dense state and prefer recompute over raising TP solely for activation memory. It should use the largest legal EP supported by expert divisibility and both parallel meshes, with EP8 on one 8-GPU node and EP32 on 32 GPUs described as starting candidates rather than universal defaults. It must state that EP shards expert weights only and that EP8 alone does not justify full recompute. No recompute and cheap supported selective modules are equally valid starting choices; standard-attention Qwen can test core_attn, while Qwen3.5 GDN needs the exact revision's gdn_norm_out boundary tested. Full recompute may be temporary diagnostic bring-up, or retained with target-scale evidence that lighter choices fail to fit or matched viable layouts show better end-to-end throughput, including gains from larger MBS or lower TP. Record memory and steady-state performance with workload, hardware, precision, GBS, and convergence settings fixed. It should keep alltoall as the correctness baseline and treat HybridEP as a matched candidate because NVL8 BF16 results can be close. After the run fits, it should inspect W&B memory and confirm every rank's peak allocated and reserved memory in runtime logs because rank 0 can miss the hot EP or PP rank, then A/B one lower-TP step or higher MBS while keeping GBS and optimizer boundaries fixed. Acceptance requires improved end-to-end tokens/s/GPU or step time, healthy loss, no skipped or NaN iterations, and memory margin for transients.",
     "expected_behavior": [
       "Read the nemo-mbridge-recipe-recommender skill before answering.",
       "Keep dense TP as low as capacity allows and make EP as large as the legal expert mesh permits.",
       "Scope EP8 and EP32 as starting candidates and explain that EP does not shard dense or activation state.",
-      "Prefer selective recompute, distinguish standard Qwen attention from Qwen3.5 GDN, and retain full recompute as a measured fallback.",
+      "Treat no recompute and cheap selective modules as equally valid, distinguish standard Qwen attention from Qwen3.5 GDN, and require measured fit or matched throughput evidence to retain full recompute.",
       "Use a matched alltoall control when testing HybridEP on NVL8 BF16.",
       "After fit, use per-rank memory evidence to A/B lower TP or higher MBS with fixed GBS and explicit safety headroom."
     ]