docs(user): correct issue references and section placement

Review found three defects in the previous commit.

#1256 and #1254 are closed as not-planned, so describing the normalized
performance floors as 'tracked in' them asserted follow-up work that was in
fact declined. Reword to state the decision: the floors are deliberately fixed
absolute full-node values, and running a qualified shape is how they pass.

The new section was inserted at the same heading level as 'Query Mode' and
before its examples block, so those examples rendered under the new heading.
Move the section after them, keeping it a sibling before 'Snapshot Mode'.

The gb200-eks-ubuntu-training comment said 'the performance floors below' but
that overlay carries none — they are inherited from gb200-eks-training, and are
provisional. Say so, and note the same on the table row.

Signed-off-by: Yuan Chen <yuanchen97@gmail.com>

Author: yuanchen8911

docs/user/cli-reference.md

@@ -475,41 +475,6 @@ node shape the resolved recipe targets. See
 
 > **Service / Accelerator / OS / Intent / Platform value listings above are the OSS-embedded set.** When `--data` registers additional values (e.g., undisclosed providers, proprietary platforms), the CLI admits them at runtime through the criteria registry — see [Data Extension](../integrator/data-extension.md). `--criteria-strict` restores the OSS-only set regardless of what `--data` contributes.
 
-#### Qualified machine types
-
-Each recipe is qualified against a specific node shape. Running it on another
-machine type of the same GPU model is not blocked, but it is not qualified, and
-the consequence differs by family.
-
-| Accelerator | Service | Qualified machine type | On other shapes of the same GPU |
-|---|---|---|---|
-| `h100` | `gke` | `a3-megagpu-8g` | **Components do not schedule.** The GPUDirect-TCPXO DaemonSets pin node affinity to `cloud.google.com/gke-accelerator: nvidia-h100-mega-80gb`, so on `a3-highgpu-*` / `a3-edgegpu-8g` nothing rolls out and the deployment health check fails. GPUDirect-TCPX is not shipped — tracked in [#2290](https://github.com/NVIDIA/aicr/issues/2290). |
-| `h100` | `eks` | `p5.48xlarge` (8× H100 SXM, 32× EFA) | Deploys, but performance floors are calibrated on the full node; smaller shapes such as `p5.4xlarge` can false-fail a healthy run. |
-| `h100` | `aks` | `Standard_ND96isr_H100_v5` (8× H100 SXM) | Deploys, but as above; `Standard_NC80adis_H100_v5` (2 GPUs) and `Standard_NC40ads_H100_v5` (1 GPU) can false-fail performance gates. |
-| `gb200` | `eks` | `p6e-gb200.36xlarge` (4 GPUs per K8s node) | Deploys; floors are sized for this shape. |
-| `a100` | `gke` | `a2-highgpu-*` / `a2-ultragpu-*` | GPUDirect is not applicable; the `gke-nccl-tcpxo` component is intentionally omitted. |
-| `b200` | `gke` | A4 shapes | No separate NCCL plugin installer; multi-node NCCL comes from GPU Operator `gdrcopy` plus GKE A4 native multi-NIC. |
-
-Two distinct failure modes are worth separating:
-
-- **Component-level (hard).** Only GKE H100 pins artifacts to a machine type
-  today. On a non-matching shape the DaemonSets have nowhere to land and
-  deployment validation fails loudly rather than degrading.
-- **Performance-gate (soft).** Elsewhere the recipe deploys normally, but the
-  NCCL and inference floors are fixed absolute values calibrated on full,
-  high-bandwidth nodes. They are not normalized for GPU count or fabric class,
-  so a smaller shape can fail a gate while being perfectly healthy. See
-  [Validation › Node-shape assumption](./validation.md). Making these gates
-  fabric/transport-class aware is tracked in
-  [#1256](https://github.com/NVIDIA/aicr/issues/1256) and
-  [#1254](https://github.com/NVIDIA/aicr/issues/1254).
-
-Shapes not listed above are undocumented rather than known-broken: they have
-not been qualified, and the criteria model has no axis that distinguishes them.
-Whether AICR should gain one — finer-grained accelerator values, a machine-type
-axis, or a fabric class — is tracked in
-[#2377](https://github.com/NVIDIA/aicr/issues/2377).
-
 **Examples:**
 ```shell
 # Basic recipe for Ubuntu on EKS with H100
@@ -552,6 +517,45 @@ proceeds for compatibility. Use a current snapshot before deployment when you
 need conflict detection. See
 [Conflict detection requires snapshot evidence](slinky-slurm-accounting.md#conflict-detection-requires-snapshot-evidence).
 
+#### Qualified machine types
+
+Each recipe is qualified against a specific node shape. Running it on another
+machine type of the same GPU model is not blocked, but it is not qualified, and
+the consequence differs by family.
+
+| Accelerator | Service | Qualified machine type | On other shapes of the same GPU |
+|---|---|---|---|
+| `h100` | `gke` | `a3-megagpu-8g` | **Components do not schedule.** The GPUDirect-TCPXO DaemonSets pin node affinity to `cloud.google.com/gke-accelerator: nvidia-h100-mega-80gb`, so on `a3-highgpu-*` / `a3-edgegpu-8g` nothing rolls out and the deployment health check fails. GPUDirect-TCPX is not shipped — tracked in [#2290](https://github.com/NVIDIA/aicr/issues/2290). |
+| `h100` | `eks` | `p5.48xlarge` (8× H100 SXM, 32× EFA) | Deploys, but performance floors are calibrated on the full node; smaller shapes such as `p5.4xlarge` can false-fail a healthy run. |
+| `h100` | `aks` | `Standard_ND96isr_H100_v5` (8× H100 SXM) | Deploys, but as above; `Standard_NC80adis_H100_v5` (2 GPUs) and `Standard_NC40ads_H100_v5` (1 GPU) can false-fail performance gates. |
+| `gb200` | `eks` | `p6e-gb200.36xlarge` (4 GPUs per K8s node) | Deploys; floors are sized for this shape and are themselves provisional pending production NVL72 data. |
+| `a100` | `gke` | `a2-highgpu-*` / `a2-ultragpu-*` | GPUDirect is not applicable; the `gke-nccl-tcpxo` component is intentionally omitted. |
+| `b200` | `gke` | A4 shapes | No separate NCCL plugin installer; multi-node NCCL comes from GPU Operator `gdrcopy` plus GKE A4 native multi-NIC. |
+
+Two distinct failure modes are worth separating:
+
+- **Component-level (hard).** Only GKE H100 pins artifacts to a machine type
+  today. On a non-matching shape the DaemonSets have nowhere to land and
+  deployment validation fails loudly rather than degrading.
+- **Performance-gate (soft).** Elsewhere the recipe deploys normally, but the
+  NCCL and inference floors are fixed absolute values calibrated on full,
+  high-bandwidth nodes. They are not normalized for GPU count or fabric class,
+  so a smaller shape can fail a gate while being perfectly healthy. See
+  [Validation › Node-shape assumption](./validation.md). Normalizing these
+  floors per GPU or per fabric class was considered and declined
+  ([#1256](https://github.com/NVIDIA/aicr/issues/1256),
+  [#1254](https://github.com/NVIDIA/aicr/issues/1254), both closed as not
+  planned) — the floors are deliberately fixed absolute full-node values, so
+  running a qualified shape is the supported way to pass them.
+
+The table lists the accelerator/service pairs that have a qualified shape;
+a pair or a shape absent from it is **undocumented rather than known-broken**.
+It has not been qualified, and the criteria model has no axis that would
+distinguish it from one that has.
+Whether AICR should gain one — finer-grained accelerator values, a machine-type
+axis, or a fabric class — is tracked in
+[#2377](https://github.com/NVIDIA/aicr/issues/2377).
+
 #### Snapshot Mode
 
 Generate recipes from captured snapshots:

recipes/overlays/gb200-eks-ubuntu-training.yaml

@@ -23,8 +23,10 @@ spec:
   base: gb200-eks-training
 
   # Machine type: qualified on p6e-gb200.36xlarge (4 GPUs per Kubernetes node).
-  # The performance floors below are sized for that shape and are not normalized
-  # for GPU count, so another GB200 shape can false-fail a healthy run.
+  # The performance floors inherited from gb200-eks-training are sized for that
+  # shape and are not normalized for GPU count, so another GB200 shape can
+  # false-fail a healthy run. Those thresholds are themselves provisional --
+  # see the parent overlay's note.
   criteria:
     service: eks
     accelerator: gb200

recipes/overlays/h100-aks-training.yaml

@@ -25,7 +25,9 @@ spec:
   # criteria carry no machine-type axis, so they also match the smaller NCads
   # H100 shapes (Standard_NC80adis_H100_v5 = 2 GPUs, Standard_NC40ads_H100_v5 =
   # 1 GPU). Those deploy normally, but the performance floors below are fixed
-  # absolute full-node values and can false-fail on them. See #1256/#1254.
+  # absolute full-node values and can false-fail on them. Normalizing them was
+  # declined (#1256, #1254 — both closed not-planned); the qualified shape is
+  # the supported way to pass them.
   criteria:
     service: aks
     accelerator: h100

recipes/overlays/h100-eks-training.yaml

@@ -26,7 +26,9 @@ spec:
   # (e.g. p5.4xlarge). Those deploy normally — unlike the GKE leaf, no component
   # here pins node affinity to a shape — but the performance floors below are
   # fixed absolute values calibrated on the full node, so a smaller shape can
-  # false-fail a healthy run. Normalizing the gates is tracked in #1256/#1254.
+  # false-fail a healthy run. Normalizing them per GPU/fabric class was declined
+  # (#1256, #1254 — both closed not-planned); the floors are deliberately
+  # absolute, so the qualified shape is the supported way to pass them.
   criteria:
     service: eks
     accelerator: h100