The earlier stackable orbital rack established a useful invariant: permanent rails carry the spacecraft, while functional cartridges leave sideways. That idea survived. The object around it did not.
Once we made the power surface physical, put every resident function into the mass ledger, closed a launch load path, and asked how several units should cooperate, the long generic rack stopped being the architecture. It became the service spine inside a larger, autonomous cell. Four of those cells then became the smallest useful data-centre pod.
The interactive model shows all three levels. Switch between the earlier sketch, one evolved cell, and the four-cell pod. Separate the cell’s layers, extract its compute cassette, or remove one workload cell from the pod. The geometry is simplified for the browser, but its dimensions and topology follow the current NRC-600 engineering model.
What changed
| Earlier render | Evolved design | What forced the change |
|---|---|---|
| One rack grows anti-Sunward | One bounded autonomous cell; scale-out happens sideways at pod level | PV, radiator, shield, plume, field-of-view, and attitude surfaces do not compose by extending one axial chain |
| A mostly schematic power head | Four rigid 2 × 2 m PV quadrants carrying 60 removable 499 mm tiles | The 3 m power case failed the worst-eclipse energy ledger, while thousands of individually exposed cells were a poor robotic service unit |
| Shield and radiator looked like variations of one parasol | A 4.30 m transparent Sunward bumper and a separate 3.1 m anti-Sun radiator, each with its own booms, restraints, and service state | Particle interception and heat rejection have different materials, view requirements, failure modes, and maintenance operations |
| The slim rack appeared to be the whole load path | The rack carries services and cartridges inside an 870 mm co-load exocage | Complete mass, propulsion, and root-moment closure overwhelmed the inherited slender rail allocation |
| Stack order looked generic | Permanent segments launch in final order; only cartridges routinely leave sideways | Storage venting, propulsion plume clearance, sensor fields of view, thermal paths, and launch loads make position part of the interface |
| One power head implied one growing data centre | Four complete cells on a 6 m pitch form the first pod | Four gives 75% workload after one cell is taken offline and two routes around the perimeter without creating a central-hub cut |
| Shared infrastructure was an easy future option | Power, storage, thermal transport, propulsion, and safe control remain cell-local | Pooling unlike domains would turn scale into a common-mode fault; the pod shares only structure, bonding, data, time, and coordination |
This is the important kind of design change: the first model was not discarded. Its best rule—permanent structure, laterally replaceable function—became an internal invariant of a more complete system.
One cell is now a complete failure domain
The Sunward end is a rigid 4 × 4 m photovoltaic field split into four deployable quadrants. An 8 × 8 bay grid leaves its central 2 × 2 bays open, producing 60 physical tiles and a service well. The current engineering point carries four launch spares in a captive magazine and uses a central presenter to hand tiles to a rear servicing vehicle.
Above the array, a transparent four-sector particle bumper stands 450 mm from the PV plane. It can lift another 200 mm for tile service. Below the array, the independent annular radiator deploys at 2.4 m anti-Sunward and keeps a 1 m service opening through its centre. Neither surface borrows the other’s structure or qualification claim.
The anti-Sun rack holds wheel, storage, compute, avionics, and propulsion functions. Ordinary replacement is lateral: isolate a cartridge, let Hexadrone take positive custody, unload its dry interfaces, and translate it through the local +X service corridor. The permanent rails, safe-control lanes, power and data trunks, and dry thermal transport remain in place.
Closing the complete body changed the structural picture. The current allocation is about 1,375 kg wet per cell, including two independent propulsion modules. The original slender rack could no longer carry the resulting root moment and retain its modal allocation, so an 870 mm CFRP co-load exocage now surrounds the lower stack. This is why the browser model shows both structures: the inner rack remains the service grammar; the outer cage has become the primary reversible axial and bending path.
Why the first pod has four cells
One cell is autonomous, but it is not yet a useful data-centre failure topology. Two cells provide redundancy but only one path between them. Three provide a loop but no square symmetry and poorer service separation. Four cells create the first compact planar unit with all of the following:
- 6.0 kW of nominal payload compute in four 1.5 kW workload domains;
- 4.5 kW, or 75%, after one workload cell is taken offline;
- clockwise and counter-clockwise data paths around a perimeter loop;
- two grade-separated structural diagonals without a mandatory central hub;
- outward-facing cartridge extraction corridors on both rows; and
- coplanar PV, shield, and radiator surfaces that do not shadow one another by axial stacking.
The selected centres are 6 m apart. The resulting deployed hardware footprint is about 10.35 m square. Four perimeter members and two diagonals connect the cells only at their anti-Sun root planes. The diagonal crossing is separated vertically, so it does not become a fifth powered node or a single structural cut.
The pod is deliberately a weak federation. It distributes authenticated command, time, bonding, and dual-route data. It does not claim a common high-voltage bus, cross-cell battery start, shared radiator capacity, common propellant, or a central controller required for local survival. A coordinator can route workload and request net torque, but each cell retains its own safe control and resource accounting.
The launch lesson
“Stackable” originally sounded like “reorderable.” Launch integration showed otherwise.
The cell’s permanent segments now travel in final axial order inside a captured split cradle. Even an apparently attractive compute/storage reorder was rejected because the storage bay owns a position-specific vent. On orbit, a permanent segment can still be separated during an exceptional, externally supported operation, but that is not routine replacement and it is not a runtime capability.
The pod itself is not launched as one 10 m structure. Four cells separate and safe independently. Only then are their root nodes captured, the perimeter closed, the two diagonals installed on separate planes, and the redundant data paths tested. This cleanly separates launcher ownership from orbital infrastructure assembly.
What the new render does—and does not—claim
The visualization carries the selected topology and the dimensions that explain it: 60 hard PV tiles, independent shield and radiator planes, lateral cartridge service, the inner rack and outer exocage, four cells on 6 m pitch, outward service axes, and the loop-plus-diagonals pod fabric.
It is still an architecture model. It does not select flight laminates, transparent bumper material, solar-cell product, radiator construction, deployment actuators, connectors, propulsion hardware, truss stowage, or Hexadrone tooling. It does not prove coupled flexible dynamics, ballistic performance, plume compatibility, thermal distortion, or qualification.
The design has nevertheless crossed a useful threshold. The previous render asked, “Can an orbital rack keep growing?” The evolved design gives a more disciplined answer:
Let the rack grow only inside a bounded autonomous cell. Let the data centre grow by connecting complete cells without merging the failure domains that keep each one alive.