Preview FINAL · Nvidia standardisation boundary

FINAL PREVIEW · NVIDIA STANDARDISATION BOUNDARY

Where does Nvidia's spec end?

FINAL · TWO VISUALS · READY TO INTEGRATE

Visual 1 answers the reader's question directly: the dual-path control architecture, with the Nvidia-defined event/orchestration path across the top and customer-owned critical-safety actuation across the bottom. Boundary made explicit.

Visual 2 grounds the abstract boundary in physical geometry. The physical rack chassis and the logical control plane don't coincide. The shaded overlay makes that gap visible.

Both cite four verified Nvidia primary sources: DSX Exchange architecture + stateless async bus + NICo Key Capabilities + Mission Control 2.3 BMS-BCM integration.

Visual 1 · Dual-path control architecture

Two parallel sensor paths converge on NICo + Mission Control. Path A (Nvidia-managed) runs cold plate + inner-manifold sensors through the BMC. Path B (BMS-managed) runs facility-scale sensors through the customer BMS, exchanging events with NICo via DSX. Below NICo, three outputs: workload plane (health + allocation), compute-actuation plane (tray shutdown), event plane (BMS event exchange). Below the boundary line, customer-owned actuators — rack AC breaker, coolant valve, facility escalation.

Nvidia leak-detection control path — dual sensor paths converging on NICo, with a critical-safety boundary at BMS OPTION 2 · v3 · CONTROL PATH · DUAL-SENSOR EVENT-TO-ACTION Nvidia's own docs draw a clean boundary. The event and orchestration path is Nvidia-defined and crosses the rack/facility line via DSX event exchange. Critical safety actuation stays with the customer's BMS. NVIDIA-DEFINED · EVENT AND ORCHESTRATION PATH PATH A · COMPUTE-TRAY (NVIDIA-MANAGED) Cold plate + manifold 2 sensors per tray BMC Redfish exposure PATH B · FACILITY-SCALE (BMS-MANAGED, DSX EXCHANGED) Rope · spot · CDU + drip pan sensors BMS event-ingest side DSX event bus NICo + Mission Control Both paths converge here Discovery via Redfish Severity classification Policy engine + workload API Health + allocation Block new allocations Migrate workloads workload plane Tray shutdown Graceful, gravity-aware of affected trays actuation · compute BMS event exchange Request rack isolation via DSX stateless async event plane NVIDIA · CUSTOMER · CONTROL INTERFACE CUSTOMER · CRITICAL SAFETY ACTUATION Rack AC breaker BMS opens circuit Site-picked breaker firmware critical safety · BMS-owned Coolant valve closure BMS actuates valve Site-picked valve topology critical safety · BMS-owned Facility escalation BCM ticketing Onsite operator dispatch operator + BCM The boundary in one line Nvidia can standardise the event and orchestration path without owning the physical facility safety system. The sensor standardises; the economic control point moves into the event, policy and workload response layers. SOURCES · [P1] Nvidia Infra Controller · Key Capabilities docs.nvidia.com ("Critical safety actions remain with BMS; NICo handles orchestration") · [P1] docs.nvidia.com/dsx-exchange/architecture + stateless-async-bus · Mission Control 2.3 BMS integration · adikumar.co · 2026-09-21

Fanout geometry cleaned up: single stem from NICo, single horizontal branch at Y=306, three vertical drops into the outputs. No crossing lines.

Visual 2 · Physical boundary vs logical control plane

Same underlying architecture, grounded in the physical rack + facility topology. Two boundaries are drawn distinctly: the solid vermillion box is the physical compute-tray chassis (Nvidia's physical zone); the shaded vermillion overlay is the logical control plane, which extends beyond the chassis into BMS event ingest via DSX event exchange. Physical safety actuation (breakers, valves, facility escalation) stays outside the control plane, customer-owned.

The BMS is split into two sub-boxes to make the point precisely: the event-ingest side sits inside Nvidia's control plane (subscribed via DSX); the actuator side sits outside, driving breakers and valves per site-picked policy.

Physical vs logical boundary — Nvidia's control plane crosses the compute-tray chassis via DSX event exchange OPTION 3 · v2 · PHYSICAL BOUNDARY VS LOGICAL CONTROL PLANE Two boundaries. The physical rack chassis is Nvidia's compute-tray. The logical control plane extends beyond the chassis via DSX event exchange into BMS event ingest. Physical safety actuation (breakers, valves) stays customer-owned regardless. FACILITY · BMS-managed physical zone NVIDIA CONTROL PLANE (LOGICAL) FACILITY SENSORS Rope perimeter rack + hall Drip pan spots under-floor + CDU CDU sensors pressure · flow NVIDIA COMPUTE-TRAY physical chassis boundary Cold plate idx 0 Manifold idx 1 BMC → NICo / Mission Control DSX event bus BMS · event ingest Receives DSX events Publishes state to NICo inside Nvidia's control plane BMS · actuator Drives breakers + valves Site-picked policy outside Nvidia's control plane CUSTOMER ACTUATORS AC breaker Coolant valve LEGEND Solid vermillion: Nvidia physical zone (compute-tray chassis) Shaded vermillion: Nvidia control plane (logical boundary — extends into BMS event ingest via DSX) Dashed black: customer physical zone (facility) SOURCES · [P1] docs.nvidia.com/dsx-exchange/architecture ("BMS → NICo: coolant leak events so NICo can cordon nodes and migrate workloads") · [P1] docs.nvidia.com/infra-controller/documentation/overview/key-capabilities · Mission Control 2.3 BMS-BCM · adikumar.co · 2026-09-21

Addresses the "Nvidia = rack, customer = everything else" trap: the boundary is logical, not physical. The overlay makes visible that the control plane crosses the chassis.

Thesis to sharpen in §12

Current wording ("the response path and controls would continue to differentiate") is too broad for the level of Nvidia standardisation now on the record. New wording that survives the "Nvidia standardises everything" critique:

The sensor can standardise. The economic control point moves into the event, policy and workload response layers. Nvidia can standardise the event and orchestration path without owning the physical facility safety system.

Next step: confirm and I'll integrate Visual 1 as new Fig L4nv3 in §04c (or replace L4nv2), keep Visual 2 as an optional secondary in §04c, and tighten §12 in one PUT.