The Cislunar Transportation Spine

Abstract

A durable deep-space program needs a transportation service, not merely a collection of launch vehicles. I divide the cislunar corridor into Earth launch, aggregation, translunar transfer, lunar-orbit staging, surface descent, ascent, and return. Each segment has a distinct energy, safety, cadence, and reuse problem. The architecture becomes resilient when payloads can change carriers at standard interfaces, uncrewed cargo can travel slowly, crews remain attached to credible abort paths, and failed equipment can move backward for repair. I propose a hub-and-spine model anchored by staging orbits and surface ports, derive the mass leverage of staging, and establish a fleet-sizing method based on throughput and availability. The design rejects reuse as a slogan. A reusable vehicle only creates value when inspection, refueling, spares, and turnaround are themselves part of the infrastructure.

Treat the corridor as a chain of services

Earth launch will remain an essential and violent boundary. It does not need to dictate the complete vehicle that reaches the Moon. A payload that carries atmospheric ascent structure, translunar propulsion, lunar descent hardware, surface equipment, and all associated margins in one stack forces every kilogram through every environment.

I instead divide the route into legs. Launchers place standardized payloads and propellant into an aggregation region. Transfer stages move them through cislunar space. A lunar-orbit node provides navigation, shelter, inspection, limited maintenance, and exchange. Landers specialize in the descent and ascent environments. Surface mobility carries cargo away from the landing zone.

Gateway demonstrates several characteristics of this service logic. NASA describes a station in near-rectilinear halo orbit that can operate uncrewed, support visiting vehicles, use international interoperability standards, and receive logistics spacecraft. I do not assume that one station or one orbit must serve all traffic. I take the deeper lesson: staging assets can decouple transportation legs and allow functions to persist between crews.

EarthLaunch and aggregate TransitTransfer and navigate Lunar orbitStage and inspect SurfaceLand, unload, and return

Separate people from ordinary cargo

Crew transportation is governed by time, radiation, life support, launch escape, abort geometry, medical risk, and safe return. Bulk cargo is governed by delivered mass, handling, storage life, and schedule. Combining them by default makes cargo unnecessarily expensive and crew missions unnecessarily congested.

I would reserve fast, highly assured trajectories and vehicles for people, critical medical equipment, and time-sensitive material. Power units, shielding, construction equipment, food reserves, and feedstock can travel on slower routes when thermal and radiation limits allow. Electric-propulsion tugs can trade transit time for propellant efficiency. Predeployment lets a crew depart only after surface power, communications, shelter, consumables, and ascent capability have reported healthy.

This creates a simple readiness rule:

$$P(\text{crew departure}) = 0 \quad\text{until}\quad S_{power}S_{hab}S_{return}S_{comm}=1,$$

where each $S$ is a verified state, not a planned delivery. The rule prevents schedule pressure from converting an unfinished cargo campaign into a human emergency.

Staging changes the mass ledger

The rocket equation explains why moving propellant and dry structure through several velocity changes is costly:

$$\Delta v = I_{sp}g_0\ln\left(\frac{m_0}{m_f}\right).$$

For a chemical stage with $I_{sp}=450\ \mathrm{s}$ and a required $\Delta v=2.5\ \mathrm{km/s}$, the ideal mass ratio is

$$\frac{m_0}{m_f} =\exp\left(\frac{2500}{450(9.806)}\right) \approx1.76.$$

That ratio is before reserves, losses, tanks, engines, landing gear, and payload integration. If the same dry vehicle can refuel near the start of a repeated leg, its structure need not be relaunched for every trip. The benefit is not free. Refueling demands tankers, storage, transfer, measurement, leak control, thermal management, and inspection. A staged architecture moves mass from flight hardware into infrastructure and operations.

I would evaluate each stage through delivered payload fraction, annual throughput, loss exposure, and turnaround labor rather than advertised reusability.

Vehicle role	Primary design pressure	Sensible recovery strategy
Earth launcher	Atmospheric ascent and launch cadence	Provider-specific refurbishment or disposal
Orbital tug	Efficient repeated transfer	Inspect and refuel in orbit
Crew transport	Abort and return assurance	Return to controlled Earth servicing
Lunar lander	Deep throttling, dust, and surface access	Inspect at surface and orbital ports
Cargo hauler	Low cost per delivered kilogram	Modular propulsion and replaceable pallets

Ports must do more than dock

A transportation node needs capture volume, relative navigation, traffic rules, structural load paths, electrical power, data exchange, thermal limits, fluid interfaces, quarantine, fire separation, robotic handling, and authority transfer. The physical ring is only the visible edge of a larger contract.

I would standardize three cargo scales: hand-carried packages, robot-handled pallets, and vehicle-class modules. Every unit receives mass properties, keep-out geometry, lifting points, power state, hazardous-material declaration, data identity, and restraint status. A pallet should move from launcher to tug to lander to surface transporter without workers improvising a new sling at each boundary.

ApproachNavigation and traffic

Defines corridors, right of way, abort boxes, and relative-state quality.

CaptureStructure and restraint

Transfers dynamic loads through verified mechanical paths.

ExchangePower, data, fluid, and cargo

Provides measured services through isolated interfaces.

ReleaseAuthority and configuration

Confirms ownership, health, clearance, and departure state.

Reuse requires a maintenance economy

A lander that flies ten times but requires a unique launch of technicians, tools, and spares before every sortie may not reduce system burden. I define effective reuse by the ratio

$$R_{eff}=\frac{M_{payload,life}} {M_{new\ hardware}+M_{spares}+M_{service\ logistics}}.$$

The numerator counts useful payload delivered over the vehicle’s life. The denominator counts the material that must be launched to create and preserve that service. The metric is incomplete because it omits risk and money, but it exposes maintenance hidden outside the vehicle brochure.

Reusable assets need accessible inspection zones, permanent health monitoring, replaceable propulsion and avionics units, known life limits, safe propellant conditioning, and a route for hardware that cannot be repaired locally. The spine must carry broken equipment backward. A logistics system that only moves outward will accumulate unusable mass and unresolved hazards.

Capacity must follow demand without losing resilience

For vehicle class $j$, annual service capacity can be screened as

$$C_j=N_j q_j A_j,$$

where $N_j$ is fleet count, $q_j$ is nominal trips per year, and $A_j$ is operational availability. Three landers nominally capable of four sorties each at 75 percent availability yield nine expected sorties, not twelve. If campaign survival requires eight, the arithmetic margin is one sortie before correlated failures, weather, launch delays, or maintenance bottlenecks.

I would size fleets through event simulation rather than average demand. Cargo arrives unevenly. Crews create deadlines. A tanker delay can idle several vehicles. One hard landing may close a pad and consume the only heavy lift asset. The model must include queues, spares, inspection bays, propellant inventory, crew windows, and rescue reservations.

The first cislunar spine should be modest: standard payload records, compatible capture and service interfaces, navigation coverage, at least two independently recoverable cargo paths, and demonstrated transfer of a failed unit back toward Earth. Its success will be measured when the next mission can use the corridor without belonging to the program that built every part of it.