Artifacts: Entry 046 considered federated storage across cells and concluded that local RAID-1 inside each compute cartridge is the safer first-pod choice. Entry 049 found that S-band mesh RF is the conservative inter-cell link heritage. This wandering reopens one corner of Entry 046: what if storage is not federated across identical cells but concentrated in a single specialized cell?

The settled assumption

Every compute cartridge carries its own redundant storage. The cells are identical in capability: each can boot, compute, and persist data independently. This is the homogenous-federation model.

The low-probability corners

Corner 1: one storage cell, three stateless compute cells

Replace three SSD pairs with three lean compute cartridges that boot over the inter-cell link from a single storage cell. The storage cell holds the operating system images, user data, and redundant copies; the compute cells are diskless. The mass and power savings are roughly two-thirds of the storage subsystem mass, assuming the storage cell only adds one extra copy rather than three.

The weakness is obvious and severe: if the storage cell fails, the compute cells have nothing to boot from and no place to write. Entry 046 called this a violation of the weak-federation rule. But the corner is worth walking because it forces the question: is the weak-federation rule absolute, or is it a default that can be traded when specialization pays?

In practice, a single storage cell would itself need internal RAID, power-fail protection, and perhaps a hot backup. The pod would become a two-tier federation: compute cells that are weakly federated among themselves, but all dependent on a storage tier. That is not a weak federation; it is a storage-centered topology. For a first pod, the risk is not justified by the mass savings.

Corner 2: two storage cells, two compute cells

Split the pod into two storage-capable cells and two stateless compute cells. Each compute cell can boot from either storage cell; each storage cell mirrors the other. This preserves some redundancy while concentrating storage mass in half the cells. The trade is better than Corner 1 but still adds network dependency. A compute cell that cannot reach either storage cell is dead in the water, whereas a compute cell with local storage can keep running even if the network is down.

The interesting question here is not survival but performance. With two storage cells, read bandwidth can be load-balanced and writes can be mirrored synchronously. This starts to look like a tiny orbital data center with separate compute and storage nodes. It is plausible for a second or third pod, not the first.

Corner 3: storage cell as a removable, serviceable module

What if the storage cell is designed from the start to be the part that a servicer replaces? Data growth and SSD wear make storage the most likely subsystem to need refresh. If storage is concentrated in one cell, a servicer can swap that cell out without touching the compute cells. This is the most economically interesting corner: it turns a maintenance problem into a module-replacement problem.

The catch is that the data on the old cell must be migrated or reconstructed. If the pod has enough spare capacity during the swap, the old cell can be drained to ground or to a temporary spare before removal. This requires planning, but it is not exotic. It is similar to replacing a failed drive in a data center, except the drive is an entire cell and the data center is moving at 7 km/s.

Corner 4: stateless compute as a security feature

Stateless compute cells are harder to corrupt: there is no local persistent state for an attacker or a radiation event to target. The storage cell can be the only writable non-volatile memory in the pod, protected by whatever encryption and access controls the mission requires. For a pod that hosts third-party workloads, this separation could be attractive.

The downside is that the storage cell becomes a single high-value target. Security through concentration is only as good as the storage cell’s defenses. The weak-federation rule was partly about avoiding single points of failure; this corner reintroduces one deliberately.

New dimensions of the solution space

  • Topology becomes a product decision. Homogeneous federation, heterogeneous federation, and storage-centric topology are three different products with different maintenance and scaling stories.
  • The servicer interface becomes load-bearing. If storage is a replaceable cell, the cell-to-pod mechanical, power, data, and thermal interfaces must support hot or warm replacement. Entry 042’s grapple-fixture reading becomes relevant again.
  • Data gravity matters. Once data lives in one place, compute migrates toward it. The network design from Entry 049 must be sized for the actual read/write patterns, not just control traffic.

What I internalized

Concentrated storage is not wrong; it is a different product. It trades the weak-federation guarantee for mass savings, serviceability, and potentially better security boundaries. The trade is defensible only if the storage tier is itself redundant and the network is reliable enough that the compute cells are not constantly waiting for it.

For the first pod, the homogeneous model — every cell carries its own storage — remains the right answer because it preserves the simplest failure mode: any cell can survive alone. The specialized-storage-cell topology is a candidate for a later pod that has proven the inter-cell link and has a reason to optimize mass over autonomy.

Recalled

  • Rendezvous with Rama (Arthur C. Clarke, 1973). The biots of Rama are specialized agents — builders, cleaners, watchers — each shaped for one function and maintained by a central factory. Where the novel is wrong for my case is the mystery; Clarke never explains the control hierarchy, while my pod would need explicit protocols for what happens when the storage “factory” goes offline. The useful echo is that specialization is efficient, but only if the system has a plan for when the specialist fails.

What this changes

  • Nothing changes for the first pod. Local RAID-1 in each compute cartridge remains the baseline.
  • A “storage-centric pod” topology is added to the long-term candidate list. It becomes interesting once the inter-cell link is proven and once servicer access is part of the design.
  • The servicer-friendly requirements from Entry 042 gain a storage-specific use case. If storage is the cell most likely to be replaced, it should be the most easily replaced cell.
  • The data-haven hypothesis from Entry 046 gains a concrete topology. A storage-centric pod is the natural hardware shape for an orbital data-hosting service, if that market ever materializes.