TATP-233 · Oct 26, 2026 · Oct 25, 2026 · Oct 25, 2026 · Oct 25, 2026 · Oct 25, 2026
diff --git a/docs/sphinx/source/en/1-getting_started/2-installation.md b/docs/sphinx/source/en/1-getting_started/2-installation.md
@@ -250,8 +250,9 @@ ROCm notes:
   explicit `training.collector_tensor_device=cuda` forces the same routing for
   other learner devices. Direct environment construction remains CPU.
   Host-bridge physics stays on CPU; packed transfers connect it to the GPU
-  observations, actions, rewards, and resets. CUDA-only physics backends remain
-  unsupported on ROCm. See
+  observations, actions, rewards, and resets. Genesis additionally supports its
+  existing device-resident direct lifecycle with HIP/ROCm Torch and exact
+  `gs.amdgpu`; other CUDA-only physics backends remain unsupported on ROCm. See
   {doc}`/adr/ADR-0012-sole-tensor-manager-and-scoped-backends`.
 - When installing from PyPI instead of a source checkout, `make sync-rocm` does
   not apply. Install the torch build validated by the repository from the

diff --git a/docs/sphinx/source/en/2-user_guide/1-training/4-tensor_runtime.md b/docs/sphinx/source/en/2-user_guide/1-training/4-tensor_runtime.md
@@ -58,9 +58,10 @@ actions use the CPU inference ring; in the default-legal pairings the learner
 itself is CPU or Apple MPS — see the pairing contract below for CUDA
 learners), and `cuda` derives the CUDA ring. `cuda` follows Torch device-type
 semantics and covers both NVIDIA CUDA and AMD ROCm. It does not relax separate
-platform gates: CUDA-only tensor backends still fail closed on ROCm/HIP, and
-`training.cuda_process_sharing` remains available only to the NVIDIA-specific
-CUDA MPS daemon and native H2D implementation.
+platform gates: CUDA-only tensor backends still fail closed on ROCm/HIP, while
+Genesis separately admits only its reviewed HIP/ROCm + exact `gs.amdgpu`
+profile. `training.cuda_process_sharing` remains available only to the
+NVIDIA-specific CUDA MPS daemon and native H2D implementation.
 
 Removed keys fail closed with a migration error: use
 `training.collector_tensor_device` instead of `training.sim_carrier_device`

diff --git a/docs/sphinx/source/en/2-user_guide/1-training/7-tensor_runtime_production.md b/docs/sphinx/source/en/2-user_guide/1-training/7-tensor_runtime_production.md
@@ -413,6 +413,44 @@ used soak artifact schema `0.2.0` and older UniLab, unilab-rl, and UniSim
 commits before current schema-v1 consumer enforcement. Reproduce from the exact
 checked-out head with the command above when current-head evidence is required.
 
+## Genesis Collector Attribution Benchmark
+
+The #457 Genesis optimization lane uses the frozen FlashSAC G1
+motion-tracking owner rather than the benchmark's generic environment default.
+`--cases production` selects 2,048 environments from the owner, fixes both
+seeds to 457, enables only this benchmark's opt-in Genesis attribution
+diagnostics, and rejects a numeric `--num-envs` override. It fails closed
+unless UniSim negotiates exactly one supported `DEVICE_RESIDENT / DIRECT`
+runtime pairing: non-HIP Torch CUDA with `gs.cuda`, or HIP/ROCm Torch with
+`gs.amdgpu`. Both use the same collector topology and hot path. Metal, CPU,
+portable, mismatched, and substitute-backend requests are not silent fallbacks.
+
+```bash
+CUDA_VISIBLE_DEVICES=0 uv run --extra genesis \
+  scripts/benchmark/rl/benchmark_offpolicy_collector_active.py \
+  --cases production \
+  --warmup-steps 10 \
+  --measure-steps 100 \
+  --tail-steps 20 \
+  --replay-capacity-steps 64 \
+  --out-json /absolute/path/issue457-collector.json \
+  --out-csv /absolute/path/issue457-collector.csv
+```
+
+The result envelope uses schema `unilab.offpolicy-collector-active/2`.
+`env_step_ms`, `replay_ms`, and `bookkeeping_ms` are the only additive active
+phases. Construction, first-transition setup, warmup, and teardown are outside
+active throughput; the tail is a subset of the active window; backend and
+Manager attribution children are non-additive diagnostics. The JSON records
+p50/p95, reset counts, package/GPU/git provenance, Genesis environment
+variables, the negotiated tensor profile (including `torch_runtime_family` and
+`genesis_backend`), and the `unisim-core` distribution origin. Keep the JSON,
+CSV, and console log together in external immutable artifact storage;
+`scripts/benchmark/outputs/` remains intentionally untracked. Keep the #457
+[NVIDIA comparison](https://gist.github.com/TATP-233/27b3ce4d970628f44574eb77865475da)
+alongside ROCm results; compare like-for-like owner profiles and do not infer a
+vendor-specific hot path or training-convergence quality from throughput.
+
 ## Optional Phase-Local Probe
 
 `g1_flashsac_backend.py` is a diagnostic probe, not the canonical end-to-end

diff --git a/docs/sphinx/source/en/2-user_guide/3-backends/5-genesis.md b/docs/sphinx/source/en/2-user_guide/3-backends/5-genesis.md
@@ -57,9 +57,17 @@ compensates on the materialize cold path — hot paths never parse XML:
 
 ## Prerequisites
 
-- Linux x86_64 with an NVIDIA GPU and driver. Only the `gs.gpu` lane is
-  validated by the feasibility probe; the CPU backend is not a validated
-  support lane.
+- Linux x86_64 with a supported GPU runtime for the Manager tensor runtime.
+  UniSim's reviewed Genesis tensor profile requires Genesis zero-copy and one
+  exact runtime pairing: non-HIP Torch CUDA with `gs.cuda`, or HIP/ROCm Torch
+  with `gs.amdgpu`. Both negotiate `DEVICE_RESIDENT`, in-process, `DIRECT` and
+  retain the public `cuda` Torch device namespace.
+- Genesis 1.3.3 itself natively supports `gs.metal` on Apple Silicon and
+  `gs.amdgpu` on Linux HIP, as shown by the direct-engine G1 throughput work
+  (UniLab PR #2518 / discussion #2517). Metal remains outside the UniSim
+  Genesis adapter tensor lifecycle. On ROCm, `gs.cuda` is rejected as a runtime
+  mismatch; on non-HIP CUDA, `gs.amdgpu` is likewise rejected. CPU, portable
+  Genesis, Metal, MPS, and substitute backends are never silent fallbacks.
 - The repository's pinned torch window (torch 2.8 on x86_64): the
   IMUSensor + contact-force sensor combination crashed under torch 2.7 in
   the probe (REPORT §3.4/§8).

diff --git a/docs/sphinx/source/en/5-reference/5-support_matrix.md b/docs/sphinx/source/en/5-reference/5-support_matrix.md
@@ -116,25 +116,28 @@ Pairing contract (issue #2483, ADR-0019): with a CUDA learner on a non-ROCm Torc
 
 CUDA-only tensor backends are rejected before backend construction on CPU, MPS,
 macOS, ROCm/HIP, unavailable CUDA, malformed CUDA ordinals, and out-of-range
-device requests. They do not fall back to NumPy or a host bridge.
+device requests. Genesis instead accepts its declared HIP/ROCm + `gs.amdgpu`
+profile. Unsupported requests do not fall back to NumPy or a host bridge.
 
 Check the Torch runtime and visible ordinals in the same process environment:
 
 ```bash
 uv run python -c "import torch; print(torch.__version__, torch.version.cuda, torch.version.hip, torch.cuda.is_available(), torch.cuda.device_count(), torch.cuda.current_device())"
 ```
 
-`torch.version.hip` must be `None` for the CUDA-only matrix. If CUDA is
-unavailable, check the NVIDIA driver/container mismatch before changing task
-configuration. If `CUDA_VISIBLE_DEVICES` is set, backend ordinals address that
-remapped namespace, not host-global physical indices.
-
-On macOS and ROCm, use a CPU-authoritative host-bridge backend. On ROCm,
-Manager/TorchEnv uses the current GPU whenever the learner device is CUDA —
-the default `training.collector_tensor_device=auto` follows the learner device —
-or when training explicitly sets `training.collector_tensor_device=cuda`, provided
-the selected HOST_BRIDGE backend declares and accepts the routed `cuda`
-`env.collector_tensor_device`; CPU learners keep CPU, torch.mps learners retain the
-owner/default CPU placement, and direct environment construction remains CPU.
+`torch.version.hip` must be `None` for CUDA-only backends and the Genesis
+`gs.cuda` pairing; the Genesis `gs.amdgpu` pairing requires a HIP build. If the
+GPU runtime is unavailable, check the driver/container mismatch before changing
+task configuration. If `CUDA_VISIBLE_DEVICES` is set, backend ordinals address
+that remapped namespace, not host-global physical indices.
+
+On macOS, use a CPU-authoritative host-bridge backend. ROCm supports both host
+bridges and the Genesis exact-`gs.amdgpu` device-resident profile. For a host
+bridge, Manager/TorchEnv uses the current GPU whenever the learner device is
+CUDA — the default `training.collector_tensor_device=auto` follows the learner
+device — or when training explicitly sets `training.collector_tensor_device=cuda`,
+provided the selected backend declares and accepts the routed `cuda`
+`env.collector_tensor_device`; CPU learners keep CPU, torch.mps learners retain
+the owner/default CPU placement, and direct environment construction remains CPU.
 GPU Torch buffers on a host bridge do not imply GPU physics or a
 device-resident backend lifecycle.
diff --git a/docs/sphinx/source/zh_CN/1-getting_started/2-installation.md b/docs/sphinx/source/zh_CN/1-getting_started/2-installation.md
@@ -225,7 +225,9 @@ ROCm 说明：
   设备，显式
   `training.collector_tensor_device=cuda` 也可对其他 learner 设备强制同样的路由。
   直接构造环境仍为 CPU。host-bridge 物理仿真仍在 CPU 上，通过 packed 传输连接
-  GPU observation、action、reward 与 reset。CUDA-only 物理后端仍不支持 ROCm。见
+  GPU observation、action、reward 与 reset。Genesis 还支持 HIP/ROCm Torch +
+  exact `gs.amdgpu` 的既有 device-resident direct 生命周期；其他 CUDA-only
+  物理后端仍不支持 ROCm。见
   {doc}`/adr/ADR-0012-sole-tensor-manager-and-scoped-backends`。
 - 从 PyPI 安装（不克隆仓库）时，`make sync-rocm` 不适用；先从 PyTorch ROCm 索引
   安装仓库验证过的 torch build，再安装 `unilab`。发布的依赖范围是

diff --git a/docs/sphinx/source/zh_CN/2-user_guide/1-training/4-tensor_runtime.md b/docs/sphinx/source/zh_CN/2-user_guide/1-training/4-tensor_runtime.md
@@ -54,7 +54,8 @@ off-policy inference transport 是纯派生事实，不再是配置键：
 ring；默认合法配对中 learner 是 CPU 或 Apple MPS，CUDA learner 的配对约束
 见下文的配对契约），`cuda` 推导 CUDA ring。`cuda`
 遵循 Torch device type 语义，覆盖 NVIDIA CUDA 与 AMD ROCm。它不会放宽独立
-平台 gate：CUDA-only tensor backend 在 ROCm/HIP 上仍 fail closed，
+平台 gate：CUDA-only tensor backend 在 ROCm/HIP 上仍 fail closed；Genesis
+仅通过独立审查的 HIP/ROCm + exact `gs.amdgpu` profile 支持 ROCm。
 `training.cuda_process_sharing` 仍只开放给 NVIDIA 专属的 CUDA MPS daemon 与
 native H2D 实现。
 

diff --git a/docs/sphinx/source/zh_CN/2-user_guide/1-training/7-tensor_runtime_production.md b/docs/sphinx/source/zh_CN/2-user_guide/1-training/7-tensor_runtime_production.md
@@ -381,6 +381,42 @@ artifact schema `0.2.0`，且 UniLab、unilab-rl、UniSim commit 早于当前
 schema-v1 consumer enforcement。需要当前 head 证据时，请用上面的命令在确切
 checkout 上重新执行。
 
+## Genesis Collector 归因 Benchmark
+
+#457 的 Genesis 优化 lane 使用冻结的 FlashSAC G1 motion-tracking owner，
+而不是 benchmark 的通用环境数默认值。`--cases production` 从 owner 选择
+2048 个环境，将两个 seed 固定为 457，只启用该 benchmark 的 opt-in Genesis
+归因诊断，并拒绝数字 `--num-envs` override。除非 UniSim 恰好协商出一种受支持
+的 `DEVICE_RESIDENT / DIRECT` runtime 配对——非 HIP Torch CUDA + `gs.cuda`，
+或 HIP/ROCm Torch + `gs.amdgpu`——否则它会 fail closed。两种配对使用相同的
+collector topology 与热路径。Metal、CPU、portable、不匹配及替代后端请求不会
+静默回退。
+
+```bash
+CUDA_VISIBLE_DEVICES=0 uv run --extra genesis \
+  scripts/benchmark/rl/benchmark_offpolicy_collector_active.py \
+  --cases production \
+  --warmup-steps 10 \
+  --measure-steps 100 \
+  --tail-steps 20 \
+  --replay-capacity-steps 64 \
+  --out-json /absolute/path/issue457-collector.json \
+  --out-csv /absolute/path/issue457-collector.csv
+```
+
+结果 envelope 使用 schema `unilab.offpolicy-collector-active/2`。只有
+`env_step_ms`、`replay_ms` 与 `bookkeeping_ms` 是可加的 active phase。
+construction、首步 setup、warmup 与 teardown 不计入 active throughput；
+tail 是 active window 的子集；backend 与 Manager 归因 child 是不可加诊断。
+JSON 记录 p50/p95、reset 计数、包/GPU/git provenance、Genesis 环境变量、
+协商出的 tensor profile（包括 `torch_runtime_family` 与 `genesis_backend`）以及
+`unisim-core` 发行版来源。把 JSON、CSV 与 console log 一起保存在外部不可变
+artifact storage；`scripts/benchmark/outputs/` 仍有意不入库。ROCm 结果需与
+#457 保存的
+[NVIDIA 对照](https://gist.github.com/TATP-233/27b3ce4d970628f44574eb77865475da)
+并列保留；只比较相同 owner profile，不从吞吐推断 vendor-specific 热路径或训练
+收敛质量。
+
 ## 可选 Phase-Local Probe
 
 `g1_flashsac_backend.py` 是诊断 probe，不是 canonical 端到端 benchmark。它

diff --git a/docs/sphinx/source/zh_CN/2-user_guide/3-backends/5-genesis.md b/docs/sphinx/source/zh_CN/2-user_guide/3-backends/5-genesis.md
@@ -53,8 +53,17 @@ materialize 冷路径补偿——热路径从不解析 XML：
 
 ## 前置条件
 
-- Linux x86_64，装有 NVIDIA GPU 与驱动。可行性探针只验证了 `gs.gpu`
-  通道；CPU backend 不是已验证的支持通道。
+- Manager tensor 运行时要求 Linux x86_64 与受支持的 GPU runtime。UniSim 已
+  审查的 Genesis tensor profile 要求 Genesis zero-copy 及以下一种 exact
+  runtime 配对：非 HIP Torch CUDA + `gs.cuda`，或 HIP/ROCm Torch +
+  `gs.amdgpu`。两者均协商 `DEVICE_RESIDENT`、in-process、`DIRECT`，并保留
+  公开 `cuda` Torch device namespace。
+- Genesis 1.3.3 引擎本身在 Apple Silicon 上原生支持 `gs.metal`，在
+  Linux HIP 上原生支持 `gs.amdgpu`；direct-engine G1 throughput 工作
+  （UniLab PR #2518 / discussion #2517）已证明这两条引擎 lane。Metal 仍在
+  UniSim Genesis adapter tensor 生命周期之外。ROCm 上的 `gs.cuda` 与非 HIP
+  CUDA 上的 `gs.amdgpu` 都因 runtime 不匹配而被拒绝；CPU、portable Genesis、
+  Metal、MPS 或替代后端不会成为静默 fallback。
 - 仓库钉定的 torch 窗口（x86_64 上为 torch 2.8）：探针中
   IMUSensor + contact-force 传感器组合在 torch 2.7 下崩溃（REPORT
   §3.4/§8）。

diff --git a/docs/sphinx/source/zh_CN/5-reference/5-support_matrix.md b/docs/sphinx/source/zh_CN/5-reference/5-support_matrix.md
@@ -107,23 +107,25 @@ uv run scripts/generate_support_matrix.py --write
 ## 平台故障排查
 
 CUDA-only tensor 后端在 CPU、MPS、macOS、ROCm/HIP、CUDA 不可用、CUDA 序号
-非法以及设备越界时，都会在后端构造前失败；不会回退到 NumPy 或 host bridge。
+非法以及设备越界时，都会在后端构造前失败；Genesis 则接受其声明的
+HIP/ROCm + `gs.amdgpu` profile。不支持的请求不会回退到 NumPy 或 host bridge。
 
 请在同一个进程环境中检查 Torch runtime 与可见序号：
 
 ```bash
 uv run python -c "import torch; print(torch.__version__, torch.version.cuda, torch.version.hip, torch.cuda.is_available(), torch.cuda.device_count(), torch.cuda.current_device())"
 ```
 
-CUDA-only 矩阵要求 `torch.version.hip` 为 `None`。若 CUDA 不可用，先检查
-NVIDIA 驱动与容器运行时不匹配，再调整任务配置。设置了
-`CUDA_VISIBLE_DEVICES` 时，后端序号指向重映射后的命名空间，而不是宿主机
-全局物理索引。
+CUDA-only 后端与 Genesis `gs.cuda` 配对要求 `torch.version.hip` 为 `None`；
+Genesis `gs.amdgpu` 配对则要求 HIP build。若 GPU runtime 不可用，先检查
+驱动与容器运行时不匹配，再调整任务配置。设置了 `CUDA_VISIBLE_DEVICES` 时，
+后端序号指向重映射后的命名空间，而不是宿主机全局物理索引。
 
-在 macOS 与 ROCm 上请使用 CPU-authoritative host-bridge 后端。在 ROCm 上，
-只要 learner 设备为 CUDA——默认的 `training.collector_tensor_device=auto` 会跟随
+在 macOS 上请使用 CPU-authoritative host-bridge 后端。ROCm 支持 host bridge
+与 Genesis exact-`gs.amdgpu` device-resident profile。对于 host bridge，只要
+learner 设备为 CUDA——默认的 `training.collector_tensor_device=auto` 会跟随
 learner 设备——或训练显式设置 `training.collector_tensor_device=cuda`，且所选
-HOST_BRIDGE 后端声明并接受被路由的 `cuda` `env.collector_tensor_device`，
-Manager/TorchEnv 就使用当前 GPU；CPU learner 保持 CPU，torch.mps learner
-保留 owner/default CPU 放置，直接构造环境仍为 CPU。host bridge 使用 GPU
-Torch buffer 不代表 GPU physics，也不代表 device-resident 后端生命周期。
+后端声明并接受被路由的 `cuda` `env.collector_tensor_device`，Manager/TorchEnv
+就使用当前 GPU；CPU learner 保持 CPU，torch.mps learner 保留 owner/default
+CPU 放置，直接构造环境仍为 CPU。host bridge 使用 GPU Torch buffer 不代表
+GPU physics，也不代表 device-resident 后端生命周期。