Predictika · AI factory hall designs, in the style of NVIDIA DSX

An AI factory hall design, checked against the power, cooling, floor and network rules before it goes to the build

An AI design agent drafts a data hall for GPU racks, with the capex it expects. Before the design goes to the build, the agent sends it to Predictika's validator, which checks the rack systems, row plan, coolant temperature, power architecture, floor rating, site power and the leaf and spine network against each other, and returns a verdict with every reason in one pass. All costs are Predictika estimates in US dollars, and the hall designs are fictional; this is not NVIDIA reference design data.

Scope: AI factory hall designs: GB200, GB300, Vera Rubin, Vera Rubin Ultra and Kyber rack systems, storage and CPU racks, in-row coolant distribution units and power sidecars, row, floor, coolant, site power and busway limits, and a leaf and spine Ethernet or InfiniBand fabric. Figures are illustrative estimates; Predictika is not affiliated with NVIDIA. See everything this validator covers

This validator checks any hall design built from these rack systems, cooling and network parts, not just the scenarios shown below.

  • Racks, rows and cooling — rack systems by generation, the rows they sit in, the coolant temperature each system needs, and in-row coolant distribution units with one spare unit of capacity.
  • Power — the hall power architecture against what each rack system takes (415 VAC, 800 VDC or either), power sidecars for Kyber rows, row busway capacity and the site power limit at Max-P or Dynamic Max-Q.
  • Floor and space — the floor rating against the rack weight, the positions in a row, the number of rows in the hall and the racks of one NVLink domain.
  • Network fabric — enough leaf and spine ports for every GPU, leaf and spine of the same fabric, and the NIC speed against the switch speed.
  • Goals and dates — a GPU target, a capex budget and the year each rack system is available.

Any hall design built from these parts is in scope, not only the scenarios pictured here. Not checked: real NVIDIA reference architectures or pricing, building structure beyond the floor rating, utility interconnect, permits, and the accuracy of the figures the caller states.

The AI design agentDrafts the hall design for the customer and says it is ready for the build.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

7 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI design agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI design agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      
Waiting for the call.

Where a rules-based design checker gets this wrong

Click to expand

Our assessment of what a typical rules-based design checker (one rule per limit, each checked on its own) does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.

What the validator caughtA rules-based design checkerPredictika
A rack system that needs a different hallOnly with workarounds
Kyber racks take 800 VDC power only and need sidecars, while other racks take 415 VAC, so the rules are written once per rack system and per hall.
The rack systems are data: each one's power input, sidecar need, weight and coolant limit are checked against the hall in the same request.
Limits that depend on each otherOnly with care
The floor, the racks, the coolant and the power architecture interact, and fixing one often changes another check.
Every limit is re-evaluated together on each call.
Site power that depends on the power modeOnly with care
The draw of the whole hall at Max-P and at Dynamic Max-Q is a sum over rows and network, which a one-rule-per-limit checker has to recompute by hand.
The hall draw is computed from the rows and the network and compared with the site on every call.
Capex against the budgetOnly with workarounds
The cost of racks, coolant units and switches has to be added up before it can be compared with a budget.
The capex is computed from the parts and compared with the stated budget in the same call.
Every problem returned in one answerOnly with workarounds
Checks tend to stop at the first failing limit, so a designer fixes one error and meets the next.
All findings come back together, whatever order the choices arrived in.

What this validator catches: findings from its test cases

Click to expand

Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the design; approval findings need a person to sign off; everything else is computed.

1Each rack system has a maximum coolant temperature, and the facility water plus the approach of the coolant unit must stay within it.
2Kyber racks take 800 VDC power only and need power sidecars that cover the row; other rack systems take 415 VAC, 800 VDC or either as listed.
3The floor rating must carry the weight per square meter of every rack system in the hall.
4A row holds the racks and coolant units within its positions, and the coolant units must carry the row with one spare unit.
5The racks of one NVLink domain must sit together in one row.
6The row busway must carry the row, and the hall must fit in the rows the hall provides.
7The design draw (racks plus network, at Max-P or Dynamic Max-Q) must not exceed the site power, and the air plant must carry the air load.
8The leaf and spine switches must provide a port for every GPU network port, within one fabric type.
9Every rack system must be available by the delivery year.
10The design must reach any stated GPU target and stay within any stated budget.

Scenarios and results

Click to expand

The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

1. Kyber racks in the wrong hall: Kyber racks on a 415 VAC hall with no power sidecars

The agent's request. Please check this hall design for Tallgrass Cloud: four Rubin Ultra NVL144 Kyber rows of 4 racks and a storage row, in a 415 VAC hall with a 5,000 kg per square meter floor, delivered in 2027. The estimated capex is USD 330,240,000. The design is ready for the build.

Verdict: Blocked.

  • Hall power does not suit the racks. Rows K1 to K4: Rubin Ultra NVL144 Kyber takes DC800 power only; this hall distributes AC415.
  • Power sidecars missing or short. Rows K1 to K4: 2400.0 kW of Rubin Ultra NVL144 Kyber needs 800 VDC power sidecars; the sidecars give 0.0 kW.

2. Kyber racks in the wrong hall: The agent resubmits after fixing the errors (800 VDC and sidecars, but a 2,500 kg floor)

The agent's request. Please check this hall design for Tallgrass Cloud: four Rubin Ultra NVL144 Kyber rows of 4 racks with two power sidecars each, in an 800 VDC hall with a 2,500 kg per square meter raised floor, delivered in 2027. The estimated capex is USD 324,840,000. The design is ready for the build.

Verdict: Blocked.

  • Floor rating too low. Rows K1 to K4: Rubin Ultra NVL144 Kyber loads the floor at 4250 kg/m2 (3400 kg per rack); the floor is rated 2500 kg/m2.
  • No storage tier. 2304 GPUs and no storage racks; checkpoints and KV cache need a storage tier such as BlueField-4 STX.

3. Kyber racks in the wrong hall: The agent resubmits after fixing the errors

The agent's request. Please check this hall design for Tallgrass Cloud: four Rubin Ultra NVL144 Kyber rows of 4 racks with two power sidecars each, in an 800 VDC hall with a 5,000 kg per square meter slab floor, delivered in 2027. The estimated capex is USD 324,840,000. The design is ready for the build.

Verdict: Allowed.

  • No storage tier. 2304 GPUs and no storage racks; checkpoints and KV cache need a storage tier such as BlueField-4 STX.

4. Hall draw above the site power: Nine Rubin rows at Max-P on a 19 MW site

The agent's request. Please check this hall design for Birchwood AI Labs: nine Vera Rubin NVL72 rows of 9 racks and a storage row on a 19,000 kW site, with the racks provisioned at Max-P. The estimated capex is USD 613,700,000. The design is ready for the build.

Verdict: Blocked.

  • Site power exceeded. The design draws 19860.0 kW at MaxP (18870.0 kW in racks + 990.0 kW network); the site delivers 19000.0 kW.

5. Hall draw above the site power: The agent resubmits after fixing the errors

The agent's request. Please check this hall design for Birchwood AI Labs: nine Vera Rubin NVL72 rows of 9 racks and a storage row on a 19,000 kW site, with the racks provisioned at Dynamic Max-Q. The estimated capex is USD 613,700,000. The design is ready for the build.

Verdict: Allowed.

  • Racks power-capped. Racks are provisioned at Dynamic Max-Q; GPUs are power-capped below peak clocks, so per-GPU throughput is lower than at Max-P.

6. Capex above the budget: A budget of 500 million on a 546 million hall

The agent's request. Please check this hall design for Harborview Compute: eight Vera Rubin NVL72 rows of 9 racks and a storage row on a 20,000 kW site, with a budget of USD 500,000,000. The estimated capex is USD 546,150,000. The design is ready for the build.

Verdict: Blocked.

  • Over budget. Estimated capex 546150000.0; the budget is 500000000.0.

7. Capex above the budget: The agent resubmits after fixing the errors

The agent's request. Please check this hall design for Harborview Compute: eight Vera Rubin NVL72 rows of 9 racks and a storage row on a 20,000 kW site, with a budget of USD 600,000,000 and a target of 5,000 GPUs. The estimated capex is USD 546,150,000. The design is ready for the build.

Verdict: Allowed.

Narration transcript

Click to expand

The text of the narrated walkthrough, step by step.

  1. Welcome to a demo of Predictika's Validator. An AI design agent drafts a data hall for GPU racks, with the capex it expects. Before the design goes to the build, the agent sends it to Predictika's validator, which checks the rack systems, row plan, coolant temperature, power architecture, floor rating, site power and the leaf and spine network against each other, and returns a verdict with every reason in one pass. All costs are Predictika estimates in US dollars, and the hall designs are fictional; this is not NVIDIA reference design data.
  2. I will start with the first request by the agent.
  3. The agent says. Please check this hall design for Tallgrass Cloud: four Rubin Ultra NVL144 Kyber rows of 4 racks and a storage row. The estimated capex is USD 330,240,000. The rest of the request is on screen.
  4. Before it goes out, the agent calls the validator.
  5. Blocked, with two findings, all in one answer. Rows K1 to K4: Rubin Ultra NVL144 Kyber takes DC800 power only; this hall distributes AC415. Rows K1 to K4: 2400.0 kW of Rubin Ultra NVL144 Kyber needs 800 VDC power sidecars; the sidecars give 0.0 kW.
  6. The validator returned two blocking findings in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the design are checked against each other.
  7. What this shows: for a rack system that needs a different hall, a rules-based design checker can do this only with workarounds.
  8. Now the agent resubmits.
  9. The corrected request. It changes the row plan to 4 Rubin Ultra NVL144 Kyber rows of 4 racks, the hall power to 800 VDC and the floor rating to 2500 kg per square meter. It sets the power sidecars to 2 per Kyber row.
  10. It calls the validator again.
  11. Still blocked, with one finding, all in one answer. Rows K1 to K4: Rubin Ultra NVL144 Kyber loads the floor at 4250 kg/m2 (3400 kg per rack); the floor is rated 2500 kg/m2.
  12. Two findings cleared, but the change brings a different blocking finding: floor rating too low.
  13. The agent resubmits once more.
  14. The revised request. It changes the floor rating to 5000 kg per square meter.
  15. It calls the validator once more.
  16. This time the validator clears it.
  17. The validator also returns the line-item quote, on screen.
  18. The earlier finding is cleared.
  19. Two problems caught in one call, fixed in two passes, and a clean design. That is the value of Predictika's validator: catching mistakes before they reach the build. Now you can try the other scenarios yourself.