Design • Import • Review

Design, import, and review
datacenter fabric like code.
Before the change window.

RackTwin gives network, cabling, and infrastructure teams one model for the physical layer. Start from a cut-sheet or a new topology, catch drift and blast radius before technicians touch the floor, then generate the BOMs, labels, and work orders your build depends on. Request an invite to review RackTwin with your team. Real workspace access is invite-only while we onboard design partners directly.

Start from what you have.

RackTwin works for both greenfield and brownfield teams. The goal is the same either way: turn the physical fabric into something you can validate, review, and hand to operations without spreadsheet archaeology.

IN

Import existing fabric

Upload a cut-sheet or observed state, infer structure, and get a project you can review instead of another one-off spreadsheet.

DS

Design new fabric

Start from intent, expand into structure and materialized topology, and keep design choices reviewable before anything ships to the floor.

RV

Review before the floor changes

Validate invariants, check drift, simulate cable failures, and generate artifacts from the same model the team just approved.

Model or import. Validate and diff. Export what the field team needs.

RackTwin keeps design, operations, and workload teams on the same artifact. The workflow is simple: create or import a project, review the risk, then export the outputs tied to that exact snapshot.

Step 1

Model or import

Start from intent YAML or upload a cut-sheet. RackTwin turns both into a project with explicit structure, files, and reviewable state.

expand_intent() / import()
Step 2

Validate and diff

Run invariants, compare as-designed vs as-built state, and inspect the blast radius before a cable move becomes an outage.

validate() / reconcile()
Step 3

Simulate and export

Model failure scenarios, produce BOMs and labels, and hand operations a single set of outputs grounded in the approved topology.

simulate() / generate_artifacts()

What teams actually review before a change window.

F

Brownfield import

Bring in cut-sheets and observed state, map devices to tiers and racks, and turn messy real-world data into a project you can audit.

CSV import → mapping → project state

Constraint validation

Catch structural problems, missing redundancy, and workload-specific invariants before a design review turns into a late-night rollback.

intent · structure · graph checks
Δ

Drift Detection

Compare desired and observed state so missing, unexpected, stale, and conflicting links are visible before they surprise the next change window.

desired/ vs observed/ → reviewable diff
C

Failure simulation

Cut cables, degrade paths, or test bundle damage in software first so the team sees blast radius before the floor crew does.

cable cuts · degradation · blast radius
A

Artifacts & BOM

Generate cut-sheets, BOMs, labels, face sheets, and work orders from the same topology the reviewers just signed off on.

labels | BOM | face sheets | work orders
3D

2D + 3D proof

Use floor, rack, and cable views as evidence in the review workflow instead of relying on screenshots, tribal knowledge, or stale diagrams.

3D viewer + 2D floor + selection drill-down
~

Traffic simulation

Model utilization and traffic behavior where it matters, then connect those results back to the same racks, rails, and ports operators will touch.

ECMP | heatmaps | per-port insight
2G

Scale without abstraction loss

Use the same workflow on a small pod or a hyperscale hall without collapsing the physical detail that makes review and operations meaningful.

pods · halls · campus-scale reference topologies
>

Reviewable changes

Keep physical fabric changes in a diff-friendly workflow so architecture, operations, and workload teams can argue over one artifact instead of four versions of the truth.

YAML | Starlark | snapshots | review

Why platform and ML teams care about the physical layer.

Training schedulers and inference runtimes make assumptions about rails, planes, NVLink domains, and placement. RackTwin gives infra and workload teams one reviewable artifact to validate those assumptions before the deployment hits real hardware.

TP

Rail & Plane Awareness

Tensor parallel, pipeline stages, and all-reduce paths assume a fabric shape. RackTwin models rails, planes, and lane assignments as data the team can query, not screenshots buried in a design deck.

Rails, planes, NVLink domains as queryable structure
Mate-key functions guarantee unique port pairs
Rail isolation validated at the graph level
PR

Topology as review artifact

Infrastructure, network, and workload teams can review the same design and anchor comments to specific racks, rails, or connection patterns instead of trading screenshots and sidecar spreadsheets.

Review artifact pinned to a topology snapshot
Comments anchor to rack / tier / rail / plane
Suggested changes mutate the intent in one click
KV

Constraint Validation

Reviewers encode the invariants their workloads need — NIC counts, rail symmetry, NVLink domain shape, tier coverage — and RackTwin checks every snapshot against them before rollout.

NicsPerCompute · NvLinkDomainShape
MinSwitchesPerTier · EveryComputeConnected
Custom predicates hand-authored in Starlark

Placement impact before rollout

Change the intent, re-expand the topology, and see which racks, rails, and constraints move before a placement or capacity decision turns into an operational fire drill.

Intent edits re-expand server-side via Z3
Before/after topology diffs at rack granularity
Constraint deltas surface the impact of the change

A small input. A concrete review surface.

The input can be compact. The output should not be vague. RackTwin turns intent or imported data into something a reviewer, technician, and workload owner can all reason about.

ai_pod_960kw.intent.yaml
1kind: intent 2version: "1" 3name: "ai-pod-960kw" 4 5fabric: 6 family: clos 7 stages: 2 8 oversubscription: 9 leaf_to_spine: 1.0 10 11endpoints: 12 kind: tray 13 count: 128 14 nics: 2 15 nic_speed_gbps: 400 16 connector_type: Mpo12 17 accelerator: 18 model: "GB200-NVL72" 19 units_per_endpoint: 4 20 21placement: 22 nodes_per_rack: 8 23 racks_per_row: 8 24 rows_per_hall: 2
Expanded Output
Platform GB200 NVL72 — 2-tier CLOS
Physical scope 128 trays × 4 GPUs = 512 GPUs
Primary review Validation, diff, drift, and failure analysis
Leaf switches 16
Spine switches 32
Fabric connections 768 modeled links
Operational detail 9,216 strands and cable-level drill-down
Generated artifacts BOM, labels, face sheets, work orders
What ships to review Project files, 2D/3D proof, and exportable artifacts

Open a sample, then make it yours.

The app ships with working examples so you can explore the workflow before you stage your own data.

Cut-Sheet Import
Brownfield CSV import and mapping review
Observed state · inferred structure
Enterprise
General-purpose campus fabric
20 racks · CLOS review flow
GB200 NVL72 Pod
AI pod with workload-aware constraints
512 GPUs · 16 racks
DGX H100 SuperPOD
Reference GPU fabric
256 GPUs · InfiniBand
Single-Hall Expansion
Hyperscale hall design review
101K GPUs · 1,408 trays
2GW Campus
Campus-scale reference topology
1.18M GPUs · 64 halls
Multi-Plane Fabric
Large CLOS with plane-aware review
Fat-tree · multi-plane
Import + Reconcile
As-designed vs as-built workflow
Diffs, conflicts, and stale links

From edge pods
to hyperscale halls.

The same workflow used for small examples holds at large scale. We keep full physical detail while still running expansion, graph build, simulation, and invariant checks in CI.

2 GW
Largest validated facility
1.18M
GPUs in the largest expansion
2.2M
Graph edges at 2GW exemplar
<1s
Graph load (memory-mapped CSR)

Request an invite.
Tell us what you're building.

RackTwin workspace access is invite-only.

Reach out when you want access for a real workspace, brownfield cleanup, or a topology that needs custom modeling, validation, and artifact generation tied to one reviewable source of truth.

We are onboarding design partners directly while the product and review workflow keep evolving.

  • Brownfield cut-sheets and observed-state cleanup
  • Validation and drift rules that match your change process
  • BOMs, labels, face sheets, and work orders tied to one source of truth
  • Rail, NVLink, or connector patterns that need custom modeling
Name is required
Valid email is required
Company is required
Please select a role

Invite-only beta. We will follow up directly.

Request received.

Thanks. We received your request and will follow up directly at the email address you provided.

If you need to reach us separately, email [email protected].