The seed idea

During WWII, both the Luftwaffe (the Rettungsboje) and the RAF anchored rescue buoys / air-sea-rescue floats in the English Channel. A downed pilot or a crew off a sinking boat could swim to one: shelter, bunk, food, water, flares, a radio, dry blankets. You didn't have to make it all the way home — you had to make it to the nearest float, and then wait.

The premise here: as humans push out into the solar system over the next decades, we'll be running missions that are one failure away from being unrecoverable. Out of propellant. Out of oxygen. Out of options. There is no port to limp into and no chandlery to resupply at.

So — what if we pre-positioned caches? Passive (or lightly active) depots holding propellant, water, oxygen, food, comms relay, and shelter, parked in known, published orbits and trajectories, chosen so a ship in trouble can reach one cheaply (low Δv), drift to it, dock, and survive until rescue.

This repo is a place to play with that — mostly big-number napkin math, not a mission proposal.

The one insight that reframes everything

In the Channel, the buoy is stationary and you swim to it. In orbit, nothing is stationary and "distance" is measured in Δv, not meters.

A swimmer in the water can move in any direction for the cost of effort. A stranded spacecraft that is "out of fuel" cannot move at all — it is a ballistic object coasting on a conic section, and it will keep coasting on that exact conic forever. Two objects can be 10 km apart and need kilometers per second of Δv to actually rendezvous, because they're on different orbits moving at different velocities.

That single fact splits the whole concept into two regimes:

1. Nodes — places where things naturally congregate at low relative velocity: Lagrange points (EML1/EML2), halo/NRHO orbits, planetary parking orbits, the GEO belt. Here a passive buoy genuinely works like the Channel float: a nearby ship needs only a small Δv to close in. Park caches here.
2. Corridors — interplanetary transfer trajectories, where everything is screaming past everything else at multiple km/s. Here a randomly-placed passive buoy is useless: matching its orbit costs more Δv than a healthy ship carries, let alone a crippled one. The buoy can only help if it is on the exact same trajectory as the ship it's meant to save (the "breadcrumb / convoy" model — launch caches ahead of crews on the identical transfer), or if it has its own propulsion and comes to you (which makes it a rescue tug, not a buoy).

So the honest version of the idea inverts the Channel picture: on a transfer, the lifeboat usually has to come to the swimmer. The passive "swim-to-it" buoy only survives at the nodes. A lot of this repo is mapping which is which.

And it's not a fuel depot

The second reframing (see notes/06): the emergency is rarely "out of fuel." A ship can be fuel-rich and still dying — an O2 leak, a holed hab with the crew in suits on a countdown, a medical crisis, or simply stuck in an orbit with no way to reenter. Most failure modes are solved by refuge + air + water + power + medical + comms + a ride home, not propellant. So the buoy's most broadly useful payload is the stay-alive kit; propellant only helps the minority of failures that are actually about Δv. A network optimized as a fuel-depot grid would miss most of the ways people die out there.

The unit that makes it affordable

The reference design (notes/07) is dormant and fire-and-forget: you put it up and never think about it again. Its life support stays off — supplies sealed and inert — until a crew is detected, so shelf life is just sealed-storage physics, not decades of unattended machinery running flawlessly. It's solar-powered near the sun, RTG-powered out deep (the radiator's needed either way; the real catch for solar is decade-long battery aging). Slow ion propulsion lets it reposition, tug a stranded capsule, or — since you deliberately don't park it on a planet- impacting trajectory — retarget itself into a reentry vehicle and carry the survivors down.

And it isn't one rigid unit: you stamp out a common bus (power, propulsion, comms/beacon, autonomy, docking) and plug in modules (consumables, medical, shielding, propellant transfer, reentry kit) to make a few standardized variants — a cislunar refuge, a corridor storm-shelter, a planetary reentry lifeboat, a deep- space tug — all off the same production line. The network grows by just building more.

What's here

Running it

Everything is pure standard library — nothing to install, just Python 3.

python3 napkin.py            # Δv maps, plane-change/phasing, boiloff, coverage
python3 reachability.py      # the two-budget (Δv + time) model, validated
python3 phase1.py            # program size for what's crewed today
python3 generate_figures.py  # writes figures/*.svg + figures/index.html

To plug in your own values, edit orbital_lifeboats/presets.py (stations, design clock, responder budget, unit mass/cost) and re-run generate_figures.py — the fleet, coverage, and cost figures all re-derive from those inputs. The toolkit is importable too:

from orbital_lifeboats import reachability as R, fleet, presets
R.max_reach_angle(6, 400, presets.STATIONS[0].radius)   # reachable arc (deg)
fleet.size_full(presets.STATIONS).cost_total_b          # program cost ($B)

For the integrated page — all the documentation and every diagram woven into one self-contained, offline file — open index.html (built by generate_figures.py, or python3 build_site.py on its own). For the figures-only gallery, open figures/index.html. The canonical figures are the SVGs in figures/; PNG renders sit in figures/png/ (regenerate with figures/render_png.sh).

Running totals (the headline napkin numbers)

Run python3 napkin.py for the live version. The punchlines it produces:

• Δv is the currency. A crippled ship's reachable set is tiny. Plane changes are the killer (a 30° plane change in LEO costs ~4 km/s — more than going to the Moon).
• Phasing is nearly free. Catching up to something on your own orbit costs almost nothing but time. This is the entire reason node depots and breadcrumb convoys are viable and scatter-shot buoys are not.
• Hydrogen betrays you. Passive liquid hydrogen boils off in days to weeks. An emergency cache that must sit for years should hold storables (hydrazine, NTO/MMH), water, and gases — or carry active cooling and a power source, which deep in the outer system means nuclear, not solar.
• Blanket coverage is hopeless; node coverage is cheap. Covering all of LEO to within reach takes hundreds to thousands of buoys (you must sample every orbital plane). Covering the ~handful of places people actually go — EML1, EML2, NRHO, the ISS plane, sun-synch, GEO — takes a handful.
• The emergency is rarely "out of fuel." Air leaks, medical, breached habs, and "stuck with no way down" dominate the failure modes (notes/06). The stay-alive kit matters more than the propellant tank.
• Dormant beats stored. Keep life support off until a crew arrives and the shelf-life problem nearly vanishes (notes/07). Power it with solar near the sun, RTG out deep — the sneaky long-duration risk on a solar buoy is battery aging, not the panels.
• Build a bus, not a buoy. A common mass-produced bus + plug-in modules yields a few standardized variants per regime, instead of one rigid design that fits nowhere well (notes/07).
• Stability picks the address. A buoy that burns fuel to hold station eats its own rescue reserve, so the near-term map ranks cislunar slots by how little they drift: stage the reserve in stable orbits (DRO, EML4/5), work the busy-but-leaky ones (NRHO, EML1, crewed LEO planes), and let ion propulsion redistribute (notes/08).
• Rescue has two budgets — and the clock wins. Δv isn't enough; the rescue must finish before the air runs out, and the cheap maneuvers are the slow ones (notes/09). This splits the fleet (chemical first-responders pre-staged close; ion reserve that only repositions between calls), and the shortest life-support clock you insure against sets the network density. The phasing time-floor is one orbital period — so at GEO/NRHO the lifeboat must fly in formation with the crew, not merely share the orbit.
• It's a triage swarm, not a buoy. An echeloned response — Connect (stem the bleeding, buy time) → Sustain (diagnosis-driven resupply) → Recover (repair/tug/return) — dissolves the single-buoy contradiction, because stage 1's real product is time, and buying time makes the slow heavy echelons reachable (notes/10). You replicate the cheap medic everywhere and keep the heavy recovery rigs rare.
• Pre-position for the schedule; spend the cheap ones. Emergencies are unpredictable, but crewed activity is scheduled and risky burns fail into predictable states — so surge stage-1s out of the reserve to a planned event's failure geometry (fore/aft = energy errors, sides = pointing, plus a no-burn guardian on the original trajectory). Co-locating with where the casualty will be defeats the clock in advance, and since stage-1s are cheap they can be expendable — safety apparatus you spend just to be available (notes/11).

License

Copyright © 2026 Mick Darling. Dual-licensed:

• Code — the Python toolkit and build scripts — under the MIT License (LICENSE).
• Writing & figures — the notes, README prose, and diagrams — under Creative Commons Attribution 4.0 (CC BY 4.0) (LICENSE-CONTENT.md). Reuse freely with attribution: "Orbital Lifeboats" by Mick Darling, CC BY 4.0.

Status: sketchpad. Everything here is order-of-magnitude. Correct me, break the assumptions, push the numbers around.

01 — The core inversion

The Channel buoy works because water is forgiving

A pilot in the Channel can swim in any direction. Effort buys motion. The buoy sits still, anchored, and the swimmer closes the gap under his own power. The sea doesn't carry the buoy away at 8 km/s.

Space removes every one of those forgiving properties:

• You can't "swim." A spacecraft moves only by expending reaction mass. A ship that is out of propellant — the exact scenario that makes a lifeboat necessary — has a reachable set of essentially zero. It coasts on its current conic section and stays there.
• Nothing is anchored. A buoy in orbit is itself moving at orbital velocity. Two objects on different orbits have a large relative velocity even when they're spatially close.
• "Close" is meaningless; Δv is the metric. Two craft can pass within meters and need kilometers-per-second to actually match orbits and dock. Proximity is not reachability.

Run napkin.py §4: a ship with 100 m/s left in the tank can raise its LEO apoapsis by all of ~365 km. With 500 m/s, ~2,100 km. The crippled ship cannot come to the buoy. So either the buoy is already where the ship will be, or something with fuel must go to the ship.

Two regimes

Nodes — the buoy works as intended

Some places in space are low-relative-velocity congregation points:

• Lagrange points (especially Earth-Moon L1 and L2): quasi-stable, cheap to hold station, and everything transiting cislunar space passes nearby at low relative speed.
• Halo / NRHO orbits (where Gateway lives): same idea, a natural parking loop.
• Planetary parking orbits, the GEO belt, sun-synchronous: traffic clusters here and shares planes/energies.

At a node, a nearby ship needs only a small Δv — often just a phasing maneuver (§3, tens to ~hundred m/s) — to close in. This is where passive "swim-to-it" buoys genuinely work. Park caches at nodes.

Corridors — the buoy must come to you

Interplanetary transfers are the opposite. On an Earth→Mars trajectory you're on a heliocentric ellipse moving ~30 km/s, and anything not on your exact ellipse is moving km/s relative to you. A randomly-placed buoy in the corridor is unreachable for a healthy ship, never mind a crippled one (§2: even a 10° plane change is 1.3 km/s in LEO; heliocentric plane changes are worse).

Two ways to make a corridor lifeboat real, neither of which is a passive buoy:

1. Breadcrumb / convoy model. Launch caches ahead of the crew on the identical transfer trajectory, in the same launch window. Now the cache and the ship share an orbit, and reaching it collapses to a cheap phasing problem. The cache is a passive object, but its placement is anything but random — it's co-flown. (See 04-architectures.md.)
2. Rescue tug. A cache with its own propulsion and an active power source that maneuvers to intercept a stricken ship. This is the real generalization of the Channel buoy to open space — except the buoy now swims to you. It's a coast-guard cutter, not a float.

The reframed thesis

In the Channel, the lifeboat is passive and the survivor is mobile. In open space, the survivor is immobile and the lifeboat must be mobile — unless you place the cache where the survivor was always going to be.

And the corollary that follows from "the survivor is immobile": whatever Δv, power, comms, and navigation the rescue needs has to live in the rescuer, not the victim. The crippled party may be a bare survival capsule or a tank-dry stage with literally zero maneuvering left and a dead antenna. So the active "buoy" isn't just a supply cache that happens to have an engine — it's the element that owns the capability the victim has lost: it does the moving, it does the calling-for-help, and it's the beacon the help homes in on. The capsule's only job is to keep its crew alive and be findable. (Developed in 04-architectures.md §D.)

Everything else in this repo is working out where the survivor was always going to be (the nodes and the planned corridors), because those are the only places a passive cache earns its mass.

→ next: 02-where-buoys-work.md

02 — Where buoys actually work: a node-by-node tour

Ordered by how soon humans will be there. For each: is a passive cache viable, what should it hold, and what's the catch.

Earth orbit (now → always)

LEO. Paradoxically the worst place for a rescue-buoy network and the place that needs it least. The plane-change tax (§2) means you'd need hundreds to thousands of buoys to cover all planes (§6), and a stranded LEO craft has a built-in lifeboat anyway: atmospheric decay brings it home. A dead ship in LEO reenters in days to months. The danger in LEO is loss of life support before decay, not loss of a way home — so the useful LEO cache is a co-orbital shelter on a specific high-traffic plane (ISS/Tiangong at 51.6°, sun-synch ~98°, maybe a couple of popular smallsat shells), not a blanket network.

• Hold: O2/N2, water, food, CO2 scrubber media, a pressurized refuge, comms.
• Catch: must share the user's plane. One per popular plane, phasing covers the rest.

GEO belt. A genuine node: everything is in (nearly) one plane at one radius, all moving at the same 3.07 km/s, drifting only slowly in longitude. A dead GEO sat is stuck forever (no decay). A few caches spaced around the belt could be reached by slow longitude drift — almost pure phasing. Good candidate for propellant + a robotic refuel/reboost tug (this is basically what MEV/mission- extension vehicles already do commercially).

MEO / transfer ellipses (GTO). Awkward middle ground — high relative velocities, eccentric orbits, the Van Allen belts. Skip for caches; cover with tugs.

Cislunar (this decade → next)

The sweet spot for the whole concept, because it's full of natural low-energy nodes and the distances are still small enough that solar power works for active cooling.

• EML1 — gateway between Earth and Moon, low station-keeping. A propellant + consumables depot here serves both lunar-bound and Earth-return traffic.
• EML2 / NRHO — where Gateway orbits; the staging point for lunar surface ops. Cache here backstops surface sorties.
• Low Lunar Orbit (LLO) — last stop before descent; cache supports aborts to orbit.
• Lunar surface depots — at the poles (ice → water → O2/H2). Less "buoy," more "base annex," but part of the same survival web.

Cislunar caches can run active cryo-cooling on solar power (100% sunlight), so they can hold methalox/hydrolox, not just storables. Free-return trajectory design (see 04) means some lunar aborts need no hardware at all — the trajectory itself is the lifeboat.

Earth–Mars (next → 2 decades)

Here the corridor problem bites. Hohmann Earth→Mars is ~5–6 km/s of heliocentric Δv split across two burns (§1), and the transfer takes ~6–9 months. A crippled ship mid-transfer cannot reach an off-trajectory cache.

Viable patterns:

• Breadcrumb convoy: pre-stage caches on the same transfer in the same window. Reachable by phasing. (See 04.)
• Mars-system nodes: once you arrive, Mars has its own L-points, Phobos/ Deimos (Phobos as a propellant/ice depot is a recurring proposal), and low Mars orbit. These behave like the cislunar nodes — passive caches work again.
• Aldrin cycler: a buoy on a permanent Earth↔Mars cycling orbit (see 04) passes both planets forever, but boarding it costs the V∞ match (km/s) at each flyby. It's a habitat/way-station you rendezvous with on schedule, not an emergency float you stumble onto.

Sunlight at Mars is ~43% of Earth's — active cooling still works, but tanks and arrays grow.

Outer system (multi-decade, speculative)

Jupiter, Saturn, the asteroids. Hohmann to Jupiter is ~14 km/s and years of flight (§1). Two regime changes dominate:

1. Sunlight collapses. ~3.7% at Jupiter, ~1.1% at Saturn (§5). Solar cryo- cooling is dead. A cache out here must hold storables, water, and gas (zero-boiloff for free) or carry a nuclear power source (RTG/fission) for active cooling. Water doubles as radiation shielding, drinking supply, and — with power — splittable propellant.
2. Nodes are the moons and the L-points. The natural caches are the icy moons (Europa, Enceladus, Titan, Ceres) and Jovian/Saturnian Lagrange points. Free-floating heliocentric buoys in the outer system are nearly useless; everything worth caching clusters around the giant planets' gravity wells.

The asteroid belt is the interesting wildcard: lots of bodies, but vast spacing and a spread of orbits — a buoy network there only makes sense along established mining/transit routes, the breadcrumb model again, not a grid.

The pattern across all of it

Passive caches earn their mass at gravitationally distinguished nodes (L-points, parking orbits, moons, the GEO belt) and along pre-flown trajectories (convoys). Everywhere else — open corridors, blanket shells — you need active hardware (tugs) or you're spending more Δv to reach the lifeboat than you had to begin with.

→ next: 03-what-you-can-keep.md

03 — What you can actually keep in a cache

A lifeboat is only useful if its supplies are still good when you arrive — which might be years after it was placed. This is where physics quietly vetoes the obvious choices. Run napkin.py §5 for the timeline table.

The boiloff hierarchy

Heat always leaks in. For a cryogen, leaked heat = boiloff = lost propellant (and rising tank pressure you must vent). Passive insulation (multi-layer insulation, MLI, plus sunshades) slows it but never stops it. Roughly, from worst to best for a passive cache:

The key design fork: passive vs. active

Passive cache (MLI + sunshade, no power for cooling):

• Holds storables / water / gas indefinitely; cryogens only briefly.
• Cheap, simple, nothing to fail, nothing to keep alive.
• This is what a true emergency buoy should be — you can't assume a cooler has been running flawlessly for the 4 years since deployment.

Active / zero-boiloff cache (cryocoolers, needs continuous power):

• Holds methalox/hydrolox indefinitely — high performance on tap.
• Requires power that never quits, and power is the single point of failure.
• Solar power falls off as 1/r² (§5): 100% at Earth, 43% at Mars, 3.7% at Jupiter, 1.1% at Saturn. Past the belt, "active" means nuclear (RTG or fission), not solar.

The pragmatic cache loadout

A sensible emergency buoy probably carries a layered inventory by storability:

1. Tier 1 — always good (passive): water, O2/N2, food, CO2 scrubbers, a pressurized refuge, comms relay, medical, a charged battery, docking adapter. This is the "stay alive and call home" kit. Pure Channel-buoy.
2. Tier 2 — storable propellant: hydrazine / NTO-MMH for attitude control and modest maneuvers. Lets a stranded ship stabilize and nudge, or lets a rescue craft top off. Good for years.
3. Tier 3 — high-performance propellant (active only, node locations only): methalox/hydrolox with ZBO cooling, at cislunar/Mars nodes where solar power is strong and the cache is regularly serviced. This is the "fill the tanks and continue the mission" kit, not the "survive" kit.

Things that bite

• Pressure, not just mass. Even slow boiloff raises tank pressure; a passive cryo cache must vent, which is more loss and a tiny thrust that perturbs its orbit over years. Storables sidestep this entirely.
• Radiation degrades stuff. Food, polymers, electronics, batteries all age under GCR/SPE exposure. Water/regolith shielding helps and is dual-use.
• Propellant compatibility. A hydrolox ship can't use a methalox cache. A storables-only cache helps everyone for life support but only storables-burning craft for propulsion. Standardization (or water-as-universal-feedstock + on-site electrolysis) is a real architectural question.
• The cooler is the cache's heartbeat. Any active cache is really a small power plant that happens to hold propellant. Its reliability is the cache's reliability.

→ next: 04-architectures.md

04 — Candidate architectures

Five ways to actually build survival redundancy into a spacefaring solar system, roughly from "most like a Channel buoy" to "least." Most real systems would mix them.

A. Node depot (the true passive buoy)

What: A cache parked at a gravitationally distinguished, low-station-keeping node — EML1, EML2/NRHO, GEO belt, low Mars orbit, Phobos.

Why it works: Traffic passes nearby at low relative velocity; reaching it is a phasing/small-burn problem, not a plane change. Can be serviced and refilled on a schedule.

Holds: Tier 1 survival kit always; storables for everyone; ZBO methalox where solar power is strong (cislunar, Mars).

Best for: Cislunar (this decade) and planetary systems on arrival/departure. Weakness: Only helps craft that are near the node. Useless mid-corridor.

B. Breadcrumb convoy (the corridor solution)

What: For a planned crewed transfer, launch one or more uncrewed cargo/ cache vehicles on the identical trajectory in the same window — leading and/or trailing the crew by hours-to-days of phase.

Why it works: The cache and the crew share a heliocentric orbit, so the relative velocity is tiny and rendezvous is a cheap phasing maneuver (§3) even for a half-dead ship. You turn the open-corridor problem into the node problem by co-flying the lifeboat.

Holds: Whatever the mission's failure modes demand — propellant for an abort burn, consumables to extend life support until the next window, spares.

Best for: Earth↔Mars crewed flights, any high-stakes single transfer. Weakness: Per-mission cost; the convoy only protects that trajectory in that window. It's insurance bought per-trip, not a standing network.

This is probably the single most realistic near-term version of the idea: "every crewed Mars ship flies with a dumb cargo twin a few hours behind it."

C. Cycler way-station

What: A large habitat/cache placed on a permanent cycling orbit that repeats encounters with two bodies — the Aldrin cycler (Earth↔Mars) being the classic.

Why it's seductive: Built once, it passes Earth and Mars forever with no propellant for the transfer itself. A standing waypoint with shelter and supplies.

The catch: It flies past each planet at a hyperbolic excess velocity of several km/s. To board it you must match that V∞ — a big burn, planned in advance. So it is not an emergency float you drift onto; it's a scheduled ferry you rendezvous with deliberately. Great as routine infrastructure, weak as a contingency lifeboat (you can't catch the bus if you've already missed it).

Best for: Routine, high-cadence Earth–Mars traffic once it exists. Weakness: Unforgiving boarding Δv; fixed schedule; no help to an off-nominal ship that can't make the intercept.

D. Rescue tug (the buoy that swims to you)

What: A fueled, powered, fast-reaction vehicle stationed at a node, that maneuvers out to intercept a stricken ship and either tows it, refuels it, or takes the crew aboard.

Why it's the honest generalization: It accepts that in open space the immobile party is the victim, so the rescuer must be the mobile one — exactly inverting the Channel picture. This is the orbital coast guard.

Holds: Lots of propellant (it must afford the intercept and the return), grapple/docking gear, a crew transfer tunnel, medical.

The Δv lives in the right place. The crucial reason the active asset matters isn't just mobility — it's that the buoy is the thing that has the Δv, and the crippled capsule is the thing that doesn't. A bare-bones survival capsule, a holed habitat, or a tank-dry transfer stage may have zero maneuvering capability left. So you can't put the propulsion burden on the victim. The network's job is to concentrate Δv (and the power, antennas, and brains to use it) in the rescuer, precisely because the survivor has none. The capsule's only job is to stay alive and be findable; everything that requires moving is the buoy's job.

It also has to be the one that calls for help. Same logic applies to comms: the stricken capsule may have lost its high-gain antenna, its power, or its pointing. A standing buoy with a powered, always-on relay can (a) detect/receive a weak distress squawk, (b) relay it across the network to wherever the rescue Δv actually is, and (c) act as a navigation beacon the incoming rescuer homes on. So the active "buoy" is really three things the victim can't be: the mover, the radio, and the beacon. (This is why a passive-only network is incomplete — see the layering note below.)

Best for: GEO belt (commercially real today — mission-extension vehicles), cislunar space, anywhere with enough traffic to justify a standing asset. Weakness: Expensive, must be kept fueled and ready, range-limited by its own Δv budget. Can't save a ship it can't reach in time.

E. Trajectory-as-lifeboat (zero hardware)

What: Design the mission trajectory itself so that a propulsion failure is survivable with no intervention. The canonical example: a free-return lunar trajectory — if the engine dies after trans-lunar injection, the ship loops around the Moon and comes back to Earth on its own (this is literally what saved Apollo 13). Analogous free-return and abort-to-Earth windows exist for Mars.

Why it's the cheapest lifeboat of all: it weighs nothing. The safety is in the geometry.

Best for: Always worth layering in, especially early lunar and Mars missions. Weakness: Constrains the trajectory (often costs Δv or time vs. the optimal path), and only covers the failure modes the geometry happens to address — it gets you home, not necessarily alive if life support is the thing that failed.

How they layer

A mature architecture isn't one of these — it's all of them, matched to regime:

LEO            : co-orbital shelters on busy planes + decay-is-your-lifeboat
GEO            : node depots + rescue tugs (already commercial)
Cislunar       : node depots (EML1/EML2/NRHO/LLO) + free-return trajectories
Earth->Mars    : breadcrumb convoys per crewed flight + abort-to-Earth windows
Mars system    : node depots (Phobos, low Mars orbit, Mars L-points)
Outer system   : node depots at moons, storables/nuclear only, mining-route convoys

The thread: passive caches at nodes, co-flown caches on corridors, active tugs where traffic pays for them, and free trajectory safety everywhere it's available.

→ next: 05-open-questions.md

05 — Open questions & rabbit holes

The fun unresolved parts. Roughly: physics, systems, economics, then the weird.

Physics / trajectory

• Phasing cost, done properly. napkin.py §3 uses a crude single-burn phasing model. Do the real Lambert-solver version: given a buoy at a known phase on the same orbit and a ship with budget Δv and time T, what's the actual rendezvous cost curve? Where's the knee?
• Low-thrust changes the whole game. Everything here assumes impulsive chemical burns. A crippled ship with a working ion/solar-electric engine has a tiny thrust but potentially large total Δv given months. Does electric propulsion make off-node buoys reachable after all? (Probably yes for cargo, no for "we have 36 hours of O2 left.")
• Three-body richness. Real cislunar space has low-energy transfers (weak stability boundary / ballistic capture, the "Interplanetary Transport Network"). These could let a nearly-dead ship drift between nodes for almost no Δv — but slowly (weeks-months). Survival-time vs. Δv is the trade. Map it.
• What's the actual reachable set of a real stranded ship? Not "circular LEO + one burn" but: given a believable failure (lost main engine, RCS only; or half a tank; or full tank but a holed habitat) on a real trajectory, compute the set of caches reachable within the life-support clock, not just the Δv budget. Time is the second axis and this repo barely touches it.

Systems / engineering

• The standardization problem. A cache helps a stranded ship only if they can physically connect and exchange. Whose docking standard? Whose propellant? Whose data/comms protocol? Is water the universal currency (everyone can use it; electrolyze for O2/propellant with power) the way to dodge propellant incompatibility?
• Cache integrity over years. How do you know a buoy you've never visited still has full tanks, working comms, and no micrometeorite holes? Self- reporting telemetry + periodic robotic inspection. A lifeboat you can't trust is worse than none (you route to it and it's empty).
• The cooler-is-the-heartbeat problem. Any active cryo cache lives or dies by its power+cooling chain running untended for years. Reliability budget? Or just accept passive storables for emergency tier and reserve active cryo for routine refuel depots that are serviced often?
• Orbit maintenance. Even "stable" nodes need station-keeping (L-points are saddle points; NRHO needs periodic burns). An unattended buoy must hold its published orbit for years or it isn't where the rescue plan says it is. Self-station-keeping = propellant the cache spends on itself = less for you.

Economics / governance

• Who pays for insurance nobody wants to use? A buoy network is pure overhead until the day it saves a crew. WWII had a wartime state footing the bill. In a commercial/multi-national solar system, is this a treaty obligation (like maritime SOLAS / coast-guard duty-to-rescue), an insurance-funded consortium, or a public utility?
• Duty to rescue, in space. Maritime law obliges ships to aid those in distress. Is there / should there be an analogous space duty-to-rescue, and does that change the buoy-vs-tug math (every passing ship is a potential rescuer, so maybe you cache propellant for them, not refuge for the victim)?
• Marginal buoy value. Each added buoy covers more failure cases but at declining marginal value. Is there a clean curve: P(survival) vs. network size, for a given traffic model? That's the number that decides how big the network should be.

The weird and the fun

• Buoys as more than lifeboats. A network of known-location, powered, comms-equipped nodes is also: a deep-space relay/navigation constellation (a solar-system GPS), a science platform network, propellant depots for routine ops, and emergency caches — all the same hardware. The lifeboat case may be the justification but not the primary daily use. Does dual-use change where you put them?
• Reverse buoys / "message in a bottle." Should a stranded crew be able to release a small high-Δv beacon/sample-return capsule toward a node even if the main ship can't move? Decouple "save the data/the message" from "save the ship."
• Self-propelled smart caches. Cheap, slow, electric-propulsion caches that reposition themselves to follow predicted traffic or drift toward a developing emergency. Blurs B/D — a buoy that slowly swims.
• The grim actuarial question. At what traffic volume does a rescue network become cheaper (in expected lives + ships) than just flying with bigger margins? Early on, the answer is probably "fly with margins and free-return trajectories"; the network earns out only at scale. Where's the crossover?

Things to build next in this repo

• A proper Lambert/phasing rendezvous-cost calculator.
• A time-axis model: life-support clock vs. reachable caches.
• A toy "traffic + failures → P(survival) vs. network size" Monte Carlo.
• Real boiloff numbers per tank size (surface/volume scaling) instead of flat %/day.

06 — Failure modes (what are we actually rescuing?)

The first three notes quietly assumed the emergency is "out of propellant." It usually isn't. A ship can be fuel-rich and still doomed — a slow O2 leak, a medical crisis, a holed hab with the crew in suits on a countdown clock, stuck in an orbit with no way down. Each failure mode demands a different capability from the buoy, and propellant is only relevant to a minority of them.

That's the key reframing: this is not a fuel-depot network. It's a survival- capability network, and "fuel depot" is just one of the capabilities. The most broadly useful thing a buoy holds is the stay-alive kit, because almost every failure mode needs it and only the propulsion failures need propellant.

The taxonomy

Grouped by what capability the ship has lost, because that's what the buoy has to supply.

What the table is telling us

• The stay-alive kit beats the fuel tank. Categories B, C, D, G, I — the majority of rows — are solved by refuge + air + water + power + medical + comms, not propellant. Only A (and parts of H) need propellant or a tug. A network optimized as a fuel-depot grid would miss most of the ways people actually die.
• "Can't get down" is its own category (A3, C1, I1) and it's nasty. A ship fuel-rich but unable to reenter — or a crew that has to abandon ship entirely because the hab is gone — needs the buoy to be a lifeboat in the literal sense: something you climb into that can carry you down. That single requirement drives much of the reference design in 07.
• The crew may be unable to help themselves (E1, F1, F2). So the buoy can't assume a functioning pilot or radio on the other end. It must be able to detect, reach, and relay on its own.
• Time is the hidden axis. A suit-duration clock (C1) is hours; a consumables overrun (B6) is weeks. The same network looks very different depending on how fast the buoy has to get there. This is the model 05 flags as missing.

→ the design that tries to cover all of this: 07-the-standard-buoy.md

07 — The Standard Buoy: a reference design

Pulling the threads together (04 primitives + 06 failure modes + 03 storage) into one coherent unit. The design goal that makes it work:

Put it up, and never think about it again. It sits dormant for years to decades, costs nothing to keep, and wakes only when someone needs it. You don't maintain the network — you manufacture it. A production line keeps stamping out identical units and dropping them into more orbits and trajectories.

This is fire-and-forget infrastructure, not a fleet of tended outposts. Five design choices make that possible.

1. Power: solar by default, nuclear for the deep ones

Tier the power source by where the buoy lives, rather than going nuclear across the board:

• Inner system (LEO, cislunar, Mars) → solar. Sunlight is plentiful (100% at Earth/Moon, still 43% at Mars), panels are cheap and mass-produced, and there's no scarce-isotope supply chain throttling how many you can build. For the bulk of the network — which lives where the people are, this decade and next — solar is the right default.
• Outer system (belt and beyond) → RTG / small fission. Past Jupiter sunlight collapses to a few percent (napkin.py §5), so the deep buoys carry their own nuclear source. These are the minority, which is good, because nuclear is the production bottleneck (see below).

The radiator argument is a wash. An RTG has to dump its waste heat through a radiator — but a solar bus has to radiate its electronics and battery heat too, so both designs carry radiators regardless. Thermal management isn't a reason to prefer one over the other.

Battery aging — the solar buoy's real long-duration risk — is now largely tractable. Two developments and one architecture trick:

• Sodium-ion cells. They tolerate much wider temperature swings and take one to two orders of magnitude more charge/discharge cycles than lithium-ion. For a buoy cycling through eclipses for a decade-plus, that roughly removes cycle-life as the binding constraint (calendar aging remains, but it's far less punishing, and the wide temp tolerance eases thermal design too).
• Capacitor-buffered power pipeline: solar → capacitors → batteries. Run the always-on dormant loads off capacitors, not the battery. Supercaps have effectively unlimited cycle life and shrug off temperature, so the core stays lit (station-keeping nudges, distress receiver, beacon, health telemetry) on a component that never wears out. Solar trickles into the caps; the caps top up the batteries slowly over time; the batteries sit in reserve and are only drawn down on a call to duty — waking life support, an ion burn, a tug op. This keeps the high-energy chemistry mostly at rest (good for calendar life) and pushes all the relentless cycling onto the part that doesn't mind. The catch is energy density: caps store little for their mass, so they keep the low-power electronics alive but can't run life support alone — hence the battery for surge. That division of labor (caps = keep-alive, battery = surge) is exactly right for an asset that's 99% dormant.
• Fuel cells could do the store/release job, but they're still cycling chemical reactions back and forth, so it's not clear they age better than a good battery chemistry over decades — probably not worth the plumbing here.

Net: with sodium-ion + a capacitor-buffered pipeline, a solar buoy can plausibly sit untended for the timescales we care about, and RTG drops back to being a deep-outer-system option rather than a necessity.

And near-term is what matters. The honest scope of this exercise is the next ~10-20 years — Earth-Moon space, plus the first crewed Mars trajectories. The outer system with actual people in it is a later era that will have its own resources (in-situ propellant, local manufacturing, established nuclear infra) and its own answers; we don't have to solve Saturn today. So design for solar + sodium-ion + capacitors in cislunar space first, and let the deep variants wait until there's anyone out there to rescue.

2. Dormant life support: consumables stowed, not running

The insight that defeats the boiloff/shelf-life problem: life support doesn't run until there's someone aboard. While dormant, the cache is essentially a sealed warehouse:

• O2, N2, water, food, medical, scrubber media — all sealed and inert, not cycling. Nothing is being consumed, nothing is wearing out.
• Shelf life becomes sealed-storage physics (slow material/radiation aging), not active-system reliability (a cooler or scrubber that must run flawlessly unattended for a decade). The hardest reliability problem just evaporates because the hard systems are off.
• On detection of an incoming/arriving crew (or a received distress call), the buoy boots: spins up life support, pressurizes the refuge, brings the cabin to temperature, opens comms. Consumables start being spent only at the moment of actual use.

So you can pre-position the survival kit years in advance and it's all still there, full, the day it's needed. This is the single biggest reason the concept is even affordable: you're not paying to keep empty lifeboats running.

3. Slow-push propulsion: ion drive + storable RCS

Two propulsion systems for two jobs:

• Solar-electric / ion for the patient work: slowly repositioning itself to follow predicted traffic, drifting toward a developing emergency, or acting as a gentle tug to move a stranded capsule from one orbit to a better one — the "small push" that a crippled but occupied capsule can't give itself. Ion is high-Δv-per-mass given time, which a fire-and-forget asset has plenty of. (RTG/fission can even power the thrusters — radioisotope-electric propulsion.)
• Storable chemical RCS (hydrazine, years of shelf life) for the things ion can't do fast enough: final docking, detumble, a quick nudge, attitude control.

The Δv lives in the buoy, not the victim (the point from note 04 §D): the capsule just has to survive and be findable; the buoy does the moving.

4. It can become the reentry/landing vehicle

This is what covers failure modes A3, C1, I1 — "fuel-rich but can't get down," and "the hab is gone, we have to abandon ship entirely." The crew climbs into the buoy and the buoy takes them down.

So the buoy is built with a heat shield (or aerocapture capability) and enough control authority to place itself on a reentry/landing trajectory on demand.

Crucially — and this is your call-out — you do not park them on free-return trajectories that naturally intersect a planet. A buoy that deorbits itself is a buoy you've lost. Instead you park them on stable, non-impacting paths, but design them so it's **cheap and easy to change their path** into a reentry/landing one when they're carrying people. Easy-to-retarget, not pre-aimed-at-the-ground.

5. A bus you plug modules into — not one rigid design

Don't stamp out a single fixed unit; stamp out a common bus and configure it. This is how real spacecraft are already built (a standard satellite bus + mission- specific payloads), and it resolves the tension between "mass-produce one thing" and "the buoy near Jupiter needs to be different from the one in the ISS plane."

The common bus (stamped out at volume, identical): structure, power (solar or RTG slot — same mounting), propulsion (ion + storable RCS), avionics/autonomy, the distress receiver + beacon + relay, station-keeping, and a standardized docking port. This is the part the conveyor belt produces. You stop reasoning about each buoy and start reasoning about production rate and placement strategy.

Plug-in payload modules (matched to where it'll live and what it must do):

• consumables pack (air / water / food, sized to the regime),
• medical bay,
• propellant-transfer kit,
• storm-shelter shielding (water/regolith) for radiation modes,
• extra comms/nav relay capacity,
• reentry/landing kit (heat shield) for "carry them down" duty.

A few standardized variants, all from the same bus + module kit:

Standardized interfaces, two layers: internal (bus↔module) so the factory can mix and match, and external (one docking standard, one comms protocol, water as the universal consumable) so any ship in trouble can use any buoy. The standardization problem from 05 is a precondition, not an afterthought.

Then scatter and grow. Following 02: dense at nodes, seeded along corridors, self-repositioning via ion to fill gaps — and self-reporting health so the network always knows which buoys are good, full, and reachable. The network grows by you just building more buses and bolting on whichever modules that orbit needs.

The unit, in one breath

A mass-produced pod — solar-powered near the sun, RTG-powered out deep — that parks itself on a stable non-impacting orbit and sleeps for years — listening, beaconing, holding station — with its survival supplies sealed and its life support off. When it detects a crew in trouble it wakes, ion-drifts (or tugs the capsule) into rendezvous, opens up a pressurized refuge with air, water, power, and medical, relays the distress call, and — if there's no other way home — retargets itself onto a reentry path and carries the survivors down.

It is, at once, the float (refuge + supplies), the coast-guard cutter (Δv + tug), the radio (relay + beacon), and the lifeboat (reentry vehicle) — which is exactly what 06 says you need, because the failure that strands a crew is rarely the failure you designed the buoy around.

Where this still hurts (carried to 05)

• RTGs need fuel (Pu-238) that is scarce and export-controlled; fission units are heavier and politically fraught. Going solar-default confines this to the outer-system minority — but the deep variants are exactly the ones you can't build at volume, so the network thins out precisely where rescue is hardest.
• The quiet long-duration risk on the solar majority is battery aging, not the panels — a decade of untended charge/discharge cycling is its own reliability problem (see §1). "Fire and forget" leans on solving it.
• Heat shield + reentry capability is mass the buoy carries for years against a rare event. Worth it for the modes only it covers, but it's not free.
• "Detect a crew in trouble" is a hard autonomy + sensing + comms problem, especially for a silent capsule (failure mode F1/E1).
• A maneuverable, nuclear-powered, autonomous object you scatter everywhere is also a dual-use concern (it's a satellite that can change orbits and carry things). Governance, not physics, but real.

08 — Where they actually go (near-term cislunar map)

Yes — we can name specific slots. The near-term theater is Earth-Moon space plus the Earth↔Moon transfer corridor (and, stretching, the first crewed Mars trajectories). Within that, the placement is not a free choice: it's driven by a criterion I'd underweighted until now —

The governing criterion: station-keeping cost

A fire-and-forget buoy that has to burn propellant to hold its orbit is slowly eating the very reactant it's supposed to save for a rescue. So orbital stability is a primary selection filter, not a footnote. Cislunar slots span a wide range:

That table reorders the wish list: the slots that are best for people (NRHO, EML1 — near the infrastructure) aren't always the slots best for unattended hardware (DRO, the triangular points). The resolution is to use both kinds for different jobs.

The map

Roughly in priority order for the next decade or two.

(Δv figures are order-of-magnitude, coplanar/ideal, from napkin.py §1 and the standard cislunar Δv budget. Treat them as "which gap is bigger," not as mission planning.)

Notes per slot

• The TLI corridor (#1) is the cheapest win and partly free. Caches co-flown on a crewed lunar transfer (breadcrumb model, 04 §B) are reachable by phasing. And free-return trajectory design (04 §E) is a zero-hardware lifeboat for the transit leg — Apollo 13's actual survival mechanism. Layer it in by default.
• [†] Update (2026): Gateway was shelved in March 2026 (note 15), so NRHO is now a staging orbit, not a crewed node — the rescue demand there is transient (per-mission), not standing. The orbital mechanics below still hold.
• NRHO (#2) is the anchor of the lander architecture. It's nearly stable (~tens of m/s/yr at most). Co-locate refuge buoys with the traffic. Bonus: near- continuous Earth line-of-sight (good for the relay role) and south-pole access.
• LEO (#3) is special. Atmospheric decay is a built-in lifeboat (a dead ship comes home), so LEO doesn't need a rescue-cache grid — it needs co-orbital safe havens on the specific planes where crewed stations fly. One per busy plane; phasing covers the rest of that plane. This is the closest thing to a literal "lifeboat for the station next door," and there's historical precedent (the old ISS Crew Return Vehicle concept).
• **EML1 (#4) is the best hub but a mediocre *buoy site*** — it's a saddle point, so it needs regular station-keeping burns. Fine if it's a serviced depot; in tension with "forget it" if it's meant to be untended.
• Frozen LLO (#5) has a trap: ordinary low lunar orbits decay into the surface within months because of mascons (lunar gravity lumps). Only the frozen inclinations are quasi-stable. A buoy here must sit at a frozen inclination, or it violates the "don't put them on impacting trajectories" rule by accident.
• DRO (#6) is the standout for the design philosophy. It's stable for centuries with essentially no station-keeping — the purest "put it up and truly never think about it" slot. Higher Δv to reach than NRHO and a bit removed from surface traffic, so its role is the deep-stable reserve: park spare buoys here and let ion propulsion ferry them out to where they're needed.
• GEO (#7) is already a commercial reality (mission-extension vehicles tug and refuel dead comsats). It's uncrewed, so it's lower priority for the human rescue case, but it proves the tug-as-buoy economics today.
• EML4/L5 (#9) are free and perfectly stable but far from the action — strategic reserve, not first responders.

Sequencing

1. First (where people already are/going): TLI-corridor breadcrumbs + free-return discipline, NRHO refuge buoys, LEO safe havens on crewed-station planes.
2. Next (cislunar staging): EML1 depot, frozen-LLO abort buoys, a DRO reserve pool that ion-ferries units outward.
3. Later / commercial / strategic: GEO tugs (already happening), EML2, EML4/L5 reserve, south-pole surface annex.

The pattern that falls out: stage the standing reserve in the stable, boring orbits (DRO, triangular points), and push working buoys into the busy-but-leaky ones (NRHO, EML1, LEO planes) as traffic demands — because the bus can move itself (slowly) on ion, you don't have to launch each buoy directly to its final post. You launch to the cheap stable parking lot and redistribute.

→ open problems (detection/wake, autonomy, Δv-vs-time, governance): 05

09 — Time-vs-Δv reachability (and how it rewrites everything)

Backed by reachability.py (run it). This is the note that changes the rest of the design, because it adds the axis the first eight notes were missing: time.

The core finding: rescue has two budgets, and the clock binds first

A rescue only happens if it satisfies both:

1. Δv — can the mover afford the velocity change?
2. Time — does it finish before the life-support clock runs out?

And the cruel coupling: the cheap maneuvers are the slow ones. Drifting and phasing cost almost nothing but take many orbits; arriving fast means a high- energy transfer whose Δv explodes. So a buoy can be comfortably within Δv reach and still be useless to a crew on a short clock. Δv alone — the metric the whole repo used through note 08 — is the wrong question. The right question is "reachable before the air runs out?"

What the model shows (LEO, validated against Hohmann)

Co-orbital phasing (a buoy sharing the victim's orbit — the safe-haven / breadcrumb case). The Δv to close a phase gap drops the more orbits you allow:

Time literally buys angular reach. With a 400 m/s chemical responder, a 6-hour clock covers ~100° of co-orbital arc; a 48-hour clock covers the whole orbit.

Cross-orbit transfer (buoy on a different orbit). There's a Δv floor (the min-energy Hohmann, ~318 m/s for a 600 km gap) and arriving faster than its ~0.8 h transfer time costs Δv steeply — 6× the floor to halve the time, 40× to quarter it. A different-orbit buoy is a luxury rescue: fine on a long clock, hopeless on a short one. Co-orbital is the only thing that works under pressure.

The two findings that reshape the architecture

1. The phasing time floor is one orbital period — and it explodes with altitude

You cannot phase faster than ~1 revolution. So the orbital period is a hard floor on co-orbital rescue time, and it scales viciously:

Consequence: in deep cislunar space (NRHO) and at GEO, a buoy merely "nearby in the orbit" cannot phase in time for a short-clock emergency. Short-clock survival there requires a lifeboat docked to or formation-flying with the crewed asset — zero initial separation, zero phasing. The standing network can only cover the long-clock failure modes that far out; the fast failure modes must be handled by a lifeboat that's already right there. (This pulls the concept back toward "every station/ship carries or is shadowed by its own lifeboat" — see the failure-mode mapping below.)

2. Ion cannot first-respond — the fleet splits in two

An electric tug delivers Δv far too slowly for an emergency: even a generous 0.5 mm/s² gives ~2.3 days to produce 100 m/s, ~23 days for 1 km/s. Useless against an hours-to-days clock. So propulsion bifurcates the fleet by role:

Ion never makes the rescue burn. It moves the chess pieces while no one's dying.

How this revises notes 06–08

• Note 06 (failure modes) gains a clock column. What matters now is each mode's time budget, because that decides whether any buoy is reachable:

The shortest clock you choose to insure against sets the entire network density. Insure against suit-breach (hours) and you need dense, chemical, co-orbital responders; insure only against consumables overrun (weeks) and a sparse ion-served network suffices. That's the master design dial.

• Note 08 (placement) gets tighter and cheaper-than-feared at LEO. Coverage isn't "which orbits" — it's phase spacing on each crewed orbit. The good news: at LEO the count per orbit is small (≈2 co-orbital responders with a 400 m/s budget cover a 6 h clock across the whole ring; see reachability.py §4). The cost driver is replication per crewed plane (plane changes remain unaffordable, note 02) plus the high-orbit formation-flying requirement — not a dense grid. So: a couple of chemical responders co-orbital on each crewed plane (ISS/Tiangong/commercial-station inclinations, the active lunar corridor), docked/formation lifeboats at NRHO and GEO, and an ion-served DRO reserve behind it all.
• Note 07 (the unit) keeps both engines, with clarified roles. Chemical for the rescue burn, ion for self-repositioning — and the reachability math is why it needs both, not just nice-to-have. It also strengthens the "dormant, pre- staged" logic: responders must already be on station, close, and awake enough to move within minutes, because there's no time to ferry one in.

The one-sentence rewrite

The design is no longer "scatter caches where the Δv is cheap"; it's "pre- stage fast (chemical) responders within one-or-two orbital periods of where crews actually are, sized by the shortest life-support clock you're insuring against, and use slow (ion) reserve buoys to keep them topped up and redistributed."

Model limits (honesty)

• Two-body, planar, impulsive, Earth-centric. LEO/MEO/GEO geometries are sound; NRHO and EM-Lagrange cases are three-body and only reasoned about qualitatively (the period-floor argument carries, the exact Δv numbers don't).
• Single-revolution Lambert for cross-orbit; multi-rev solutions exist but don't change the conclusion (cross-orbit is the luxury case).
• No plane-change cost included in the rescue itself (we assume co-planar). Out- of-plane victims are simply unreachable on a short clock — which only reinforces "one responder set per crewed plane."
• Phasing model assumes rendezvous back at the maneuver point; real ops would optimize further, making it somewhat cheaper than shown. The conclusions are conservative.

Next builds this points to

• A 3-body reachability pass for NRHO/EML using a CR3BP propagator (to put real numbers on the "formation-fly your lifeboat" claim).
• A Monte-Carlo: traffic model × failure-mode/clock distribution → P(rescued) vs. fleet size and placement. That's the number that sizes the program.

10 — The triage swarm: echeloned response, not a single buoy

Stop thinking about "a buoy" (or a lifeboat, or a tug). Think about a staged sequence of inbound assistance modules that converge on a casualty in waves — a triage process. This reframing isn't just tidier; it dissolves the central contradiction the reachability math exposed.

The contradiction it resolves

Note 09 trapped the single-buoy concept: to be useful it had to be close, fast, and light (to beat the life-support clock) and heavy and complete (to actually fix the problem). Those fight. A do-everything buoy dense enough to be close everywhere is unaffordable; a complete one is too heavy to scatter.

Staging breaks the trap, because the first module's product isn't supplies — it's time. It stems the bleeding, the clock extends, and everything slower becomes reachable. The two-budget problem (Δv and time) that had no single- buoy solution turns into a solvable sequence.

reachability.py §5 shows the cascade concretely: a 6-hour LEO emergency only admits a co-orbital responder within ~100° (or a formation lifeboat alongside). But once stage 1 adds ~5 days of consumables, the clock is ~120 h — and now the full co-orbital ring is reachable cheaply, an ion tug can deliver ~200–400 m/s (so it can come from a node), and ordinary Hohmann transfers fit. Buying time turns the whole network from "unreachable" to "converging."

The echelons (with the medic/coast-guard analogy)

This is exactly echelons of care in emergency medicine and the military (Role 1 → 4: point-of-injury first aid → forward stabilization → field hospital → definitive care). Each echelon trades arrival speed against capability.

The user's phase sequence maps straight onto it: stem the bleeding (stage 1) → stabilize (stage 2) → repair → recovery → return (stage 3).

Why this is the efficient architecture

• You replicate only the cheap capability. The thing that must be dense and everywhere is stage 1 — small, light, mass-produced, chemical. The expensive, heavy stage 3 capability can be rare, because once stage 1 has bought time, stage 3 can come slowly from far away. You stop paying to put a complete hospital next to every patient; you put a medic next to every patient and one hospital in the region.
• It generalizes note 09's fleet split. That note found two roles (chemical responder / ion repositioner). The triage swarm is the richer n-echelon version: stage 1 is the chemical first responder, stage 3 is the ion reserve, and stage 2 is the middle tier the two-role model was missing.
• The modules are the plug-in payloads from note 07, now dispatched in waves instead of pre-integrated. The common bus is the same; what differs is which modules fly when, decided by the diagnosis.

Diagnosis-driven dispatch + convergence

Stage 1's connect-and-report step is the linchpin. The failure-mode taxonomy (note 06) isn't known in advance — stage 1 determines it on arrival (O₂ leak? power loss? holed hab? medical? stuck-no-way-down?). That diagnosis:

• composes stage 2's payload (radiators for a thermal failure; scrubbers for CO₂; propellant for a Δv loss; meds for an injury),
• decides whether stage 3 is even needed, and which stage 3 (a tug to move them vs. a reentry vehicle to bring them down vs. a repair rig).

Then the convergence / "homing event": from the distributed network, the nearest-reachable-in-time element of each needed echelon is tasked to flow toward the casualty. The stricken ship becomes, briefly, the node the whole local network orbits-toward. This is a many-to-one routing-and-scheduling problem layered on top of the reachability math — who can get there, with what, by when.

What it changes in the numbers

• Stage-1 density is the real cost driver (it has the hard proximity + clock constraint). But stage 1 is the cheapest unit, so dense stage-1 coverage on crewed orbits is affordable — and per note 09, even a 6-hour LEO clock needs only ~2 co-orbital stage-1s per crewed plane (plus formation lifeboats at GEO/NRHO where the period floor bites).
• Stage-3 scarcity is now acceptable: maybe a handful in the whole cislunar system, parked in stable reserve orbits, ion-ferried to wherever a stabilized casualty waits. The expensive capability stops needing to be everywhere.
• Net: the program cost reshapes from "N complete lifeboats" to "many cheap medics + some mid-tier resupply + a few heavy recovery rigs" — almost certainly cheaper for the same survival coverage.

New open questions this raises

• Command of the convergence. Who/what coordinates a multi-module, multi- origin response in seconds, possibly with a silent or incapacitated crew? An autonomous "incident commander" function has to live somewhere — stage 1, the network, or the ground (with light-lag caveats deep in cislunar space).
• Graceful degradation. What if stage 2 can't make it, or arrives partial? The echelons need to fail soft — stage 1 should buy enough time that a missed stage 2 isn't fatal, and stage 3 should be able to substitute for a failed stage 2 (at the cost of speed).
• Stage-1 sizing is now a clock-extension problem, not a supply problem: how many days of life support must "Connect" deliver to guarantee the slowest necessary stage-3 can still arrive? That product — time bought vs. stage-3 reach — is the key sizing equation, and it's the natural next calculation.

11 — Event-driven pre-positioning & expendable stage-1s

The reachability math (note 09) said rescue is hard because the cheap maneuvers are slow, so the responder has to already be close. This note is the answer to "how do you arrange to already be close?" — and the answer turns on a fact we haven't used yet:

**Emergencies are unpredictable in time and place — but most crewed activity is scheduled, and a risky maneuver fails into a predictable set of states.**

So you don't have to blanket space and hope. You pre-position responders at the specific places a planned, known-risky event could strand someone. That converts an unpredictable rescue into a scheduled rendezvous — and defeats the clock in advance, because the responder is co-located with where the casualty will actually be.

Two deployment regimes

The fleet works in two modes, drawing from the same stable reserve (DRO, L4/5):

1. Standing coverage — persistent stage-1s on crewed orbits / formation-flying with stations, for the always-there population and truly unscheduled failures. Reusable, station-kept. (This is notes 08–10.)
2. Event-driven surge — for a scheduled risky event (launch, TLI, orbit insertion, descent, a crewed transit window), ion-ferry stage-1s out of the reserve ahead of time and park them at the event's failure geometry. The lead time is days-to-months, so ion is fine for the pre-positioning move — only the rescue burn itself needs to be chemical/fast (note 09's fleet split still holds, just across time).

This mirrors how terrestrial emergency services pre-stage ambulances at a stadium on game day rather than blanketing the whole city, and how WWII air-sea rescue launches loitered offshore during a raid. You surge coverage to the known risk.

The failure geometry: fore, aft, sides — and a no-burn guardian

"Where would a failure leave them?" has structure. For a planned burn, the dispersion of outcomes maps to physical directions, so you bracket it:

• Fore / aft (along-track) — energy / burn-magnitude errors. An under-burn leaves you short and low (aft); an over-burn long and high (fore). Pre-place stage-1s ahead of and behind the nominal post-burn state.
• Sides (cross-track) — pointing / plane errors. A mis-aimed burn throws you out of plane. Lateral stage-1s cover that.
• The no-burn guardian — the discontinuous case. A total engine failure doesn't disperse you a little; it leaves you on your original pre-burn trajectory, which is somewhere else entirely. That needs its own responder pre-staged on the original path. (This is the free-return station — note 04 §E made the trajectory itself a lifeboat; here we add a hardware guardian to it.)

reachability.py §6 shows why this is so cheap for the common (dispersed) cases: a stage-1 sitting on the nominal trajectory sees a dispersed casualty depart at only ~the burn error (tens of m/s), so their separation grows slowly — a 30 m/s dispersion is ~100 km after an hour, ~650 km after six. A co-located stage-1 with a few tens-to-hundreds of m/s catches that trivially, far inside any clock. The proximity problem evaporates because you pre-arranged the proximity.

The highest-value targets: irreversible maneuvers

Pre-positioning pays most where (a) failure is catastrophic and (b) the off- nominal state is predictable. That's exactly the orbit-insertion / injection burns: miss the Mars or lunar orbit insertion and you fly past with no second chance; under-burn TLI and you're on a decaying or stranded arc. These are the moments crews are most exposed and the geometry is most knowable — so they're where a pre-staged guardian (or a ring of them) earns its keep.

Expendable stage-1s: safety apparatus you use up

The reframing inside the reframing: a pre-positioned stage-1 doesn't have to come back. It's consumable safety apparatus — you spend it simply to be available during a risky window. If the event goes nominally, the stage-1 may end up on a trajectory you can't cheaply recover, and that's an acceptable loss. It was insurance; the premium is one cheap, mass-produced module.

Why this is sound:

• The economics are lopsided. A stage-1 is the cheapest echelon (note 10); a crew + ship is not. Throwing away even several stage-1s per high-risk event is trivial insurance against losing the mission.
• It removes the recovery constraint that would otherwise force every responder onto a stable, returnable orbit. An expendable guardian can sit on a trajectory that's perfect for the rescue geometry but terrible for its own survival — e.g. one that would itself decay or escape — because it only has to exist for the hours/days of the risky window.
• Recover opportunistically, never count on it. If a spent guardian happens to end up somewhere an ion tug can fetch it later, great; design as if it won't.

What it changes in the numbers

• Standing coverage can be thinner than feared. If most high-risk exposure is during scheduled events you can pre-position for, the persistent network only has to cover the steady-state population (stations) and the genuinely unscheduled. The surge handles the rest, on demand.
• Reserve size is driven by event tempo, not by blanketing space. You need enough reserve stage-1s (plus ion ferries) to surge the busiest overlapping set of scheduled events, plus a margin of expendables per event. That's a scheduling/throughput number, not a coverage-geometry number — and it's much smaller.
• Production rate matters more than fleet size. Because stage-1s are expendable and event-driven, the conveyor belt (note 07) feeds consumption. The question becomes "how many do we burn per year of operations," which the flight schedule sets directly.

Open questions this adds

• Dispersion sizing → guardian count. How many stage-1s, and at what spacing along the dispersion ellipse, to cover a given burn's 3σ failure set? The natural calc: propagate the maneuver's covariance, tile it with stage-1 reach volumes.
• Expendable vs. recoverable accounting. At what unit cost does "throwaway per event" beat "fewer reusable guardians ion-ferried in and out"? There's a crossover set by unit cost, ferry cost, and event tempo.
• Multiplexing guardians across events. Can one pre-positioned ring cover several sequential missions through the same corridor before it's spent or recovered? Cislunar traffic is bursty around launch windows — worth exploiting.

12 — Phase 1: sizing a program for what's crewed today

Backed by phase1.py (which reuses the validated reachability.py engine). Order-of-magnitude, assumptions stated in the script.

The roster (verified May 2026)

Exactly two orbital assets are in continuous human habitation right now:

Commercial free-flyers are next window, not yet inhabited: Vast Haven-1 is now NET Q1 2027; Axiom's free-flyer ~2028. Each is Phase 1.5 — and because each is its own orbital plane, each simply adds a plane to the model (one line in phase1.py). (Sources at bottom.)

What the sizing says

Standing coverage is cheap per plane, and the cost is replication across planes. The two stations are in different planes (different inclination and precessing RAAN), and plane changes are unaffordable (note 02), so coverage can't be shared — you build it twice.

For the design clock (a catastrophic depress with the crew in suits, ~6 h of O2) and a 400 m/s stage-1 budget, the reachability model says a co-orbital responder reaches ~104° of the ring — so just 2 ring responders per plane cover it (LEO's ~93-min period means phasing fits inside the clock). Add 2 formation lifeboats per station (zero-phasing, to cover sub-period failures and to survive a station-wide event that might also disable the docked return craft).

Program cost, order of magnitude:

• Lean (just the free-flying formation refuges that add robustness beyond the docked craft; rely on decay + ground launch-on-need for the rest): ~5 units, ~15 t, ~$1B.
• Full (the echeloned network on both planes): ~17 units, ~80 t, ~$3B.

For comparison: that's about one commercial-crew development program, set against two stations worth well over $150B and crews that are irreplaceable.

Why Phase 1 is so small — and honest about marginal value

LEO is the forgiving regime, which is exactly why the number is modest:

• Short period (~93 min) → phasing rescue fits inside an hours-long clock, so you don't need many co-orbital responders.
• Atmospheric decay is a free lifeboat → "get home" is partly solved by physics.
• Stations already dock return craft (Soyuz / Shenzhou / Crew Dragon) → the return function is largely covered already.

So the network's honest marginal value in Phase 1 isn't "a way home" — it's:

1. a refuge that survives the same event that might have compromised the docked craft (fire, depress, collision, toxic release — common-cause failures),
2. coverage of a casualty that has separated from the station (a departing or arriving vehicle that fails, an EVA emergency, a debris strike during approach),
3. autonomy / response time independent of a ground launch-on-need.

That framing keeps Phase 1 lean and defensible: don't rebuild what Dragon/Soyuz already provide; add the robustness they can't.

What would change the number

• A tighter clock (fire or toxic release with minutes, not hours) pushes the whole posture toward formation-only (you can't phase in minutes) — fewer ring responders, more co-located refuges.
• More crewed stations (Haven-1, Axiom, Orbital Reef, Starlab, Bharatiya Antariksh, future Tiangong expansion) each add a plane → roughly linear growth in the standing fleet. Five commercial stations would ~triple Phase 1.
• Unit cost / launch cost are the big cost levers; Starship-class launch would drop the launch line to noise and make the full posture the obvious choice.

Roadmap (where the hard physics starts)

• Phase 1 (now): ISS + Tiangong. ~$1–3B. This note.
• Phase 1.5: commercial LEO stations as they're crewed — add planes.
• Phase 2 (Artemis / cislunar): the physics turns hostile. NRHO's ~6.5-day period breaks phasing entirely (note 09) → formation-flying lifeboats become mandatory, not optional; no atmospheric decay to bring anyone home; deep gravity wells. Pre-positioning at the insertion/injection burns (note 11) becomes the central tool, because that's where Artemis crews are most exposed and the geometry is knowable. Expect this phase to be far costlier per crew protected than Phase 1.
• Phase 3 (lunar base + mass driver): once there's a lunar surface base (even automated), a mass driver changes the delivery game — see below.

The mass-driver delivery concept (Phase 3 hook)

A lunar mass driver (electromagnetic launcher) could fling specially-prepared emergency modules off the Moon at high velocity, reaching a cislunar casualty very fast — directly attacking the time budget by brute launch speed instead of pre-positioning. Two attractive twists:

• Spend the boiloff. Propellant that would evaporate anyway (note 03) can be pre-packaged and launched as the emergency payload — turning a loss into a delivered resource.
• A fast projectile still has to match velocity at the target, or it's just a high-speed flyby. So the launched module needs onboard Δv (or a catch mechanism) to circularize/rendezvous — the mass driver provides the speed, the module provides the match. Worth modeling: lunar-launch geometry only serves trajectories reachable from the Moon's position, so it complements (doesn't replace) the pre-positioned network.

This is the natural Phase-2/3 calculation set, for the next sessions.

Sources (station roster, May 2026)

• Tiangong space station — Wikipedia
• International Space Station — Wikipedia
• The Era of Private Space Stations Launches in 2026 — SingularityHub
• NASA releases details on revised next phase of commercial space station development — SpaceNews

13 — The toolkit & figures

The first twelve notes were backed by three standalone scripts (napkin.py, reachability.py, phase1.py). Those still run and still match the notes, but the calculations now also live in a proper, reusable package so you can plug in values and regenerate everything — numbers and graphs.

The package: orbital_lifeboats/

Pure standard library (no numpy / matplotlib / anything to install). Modules:

Quick use:

from orbital_lifeboats import reachability as R, presets, fleet
R.max_reach_angle(6, 400, presets.STATIONS[0].radius)   # reachable arc, deg
fleet.size_full(presets.STATIONS).cost_total_b           # program $B

Plugging in values

Everything funnels through presets.py. Edit and re-run generate_figures.py:

• Add a station (e.g. Haven-1 when it's crewed): append a Station(...) to STATIONS. The fleet re-sizes and the per-plane coverage recomputes.
• Change the design clock (insure against minutes-not-hours): set DesignParams.design_clock_h. Watch the responder count and cost move.
• Change unit mass/cost or launch price: the cost figures track it (Starship-class launch ≈ set launch_cost_b_per_t to noise).

Because the figures are generated from these inputs, the graphs are never stale relative to the assumptions — they're one python3 generate_figures.py away.

The figures (figures/)

python3 generate_figures.py writes nine SVGs + an index.html gallery (open it in any browser). The "fire-station staging" picture, in charts:

1. Phasing tradeoff — Δv vs catch-up time per phase gap; the feasible corner.
2. Cross-orbit intercept — the Δv floor and the speed penalty.
3. Reachability map — the coverage map: phase gap × clock → cheapest rescue Δv (grey = unreachable in time). Where coverage is cheap vs costly vs impossible.
4. Period time-floor — period vs orbit; where phasing rescue dies.
5. Boiloff — what survives in a dormant cache over a year.
6. Solar power — 1/r² falloff vs distance.
7. Failure modes by clock — what we're rescuing, sorted by the time we have.
8. Coverage by regime — reachable arc vs clock for LEO/MEO/GEO (strong vs weak).
9. Program cost — Phase-1 lean (~$1B) vs full (~$3B) breakdown.

Relationship to the original scripts

napkin.py, reachability.py, phase1.py remain as the narrative/CLI versions (they print the annotated walkthroughs the notes cite). The package is the library version of the same math, plus the plotting and the figure suite. When they disagree on a fringe number it's because the package applies design rules (e.g. spares margin) uniformly; both are order-of-magnitude.

What's still missing (honest)

• Three-body (CR3BP) dynamics for NRHO/EML — the package is two-body, so cislunar figures would be qualitative until that's added.
• A Monte-Carlo coverage simulator (traffic × failure-clock distribution → P(rescued) vs fleet size) — the natural next module, montecarlo.py.
• Burn-dispersion → guardian-count tiling for the pre-positioning model (note 11).

14 — Launch vehicle sensitivity (Falcon vs Starship)

Backed by orbital_lifeboats/astro.py (Tsiolkovsky helpers) and the LAUNCHERS preset. The short version: Starship changes the constraint regime, not the physics. Module masses go up by design, the launch cost line shrinks, and the orbital mechanics don't move at all.

Mass doesn't come from the rocket — it comes from what the module must do

A module's mass is dry structure + payload + propellant. The propellant share is set by the Δv budget via the rocket equation, independent of launch vehicle:

(That last row is why a recovery tug uses ion: 2.5 km/s costs it 8% of its mass instead of 55%.) None of this depends on whether you launched on a Falcon or a Starship — it depends on the job.

What Starship actually changes

1. It removes the "lightweighting tax," so modules get heavier by choice. On Falcon you squeeze every kg (mass optimization is expensive engineering and launch is dear). On Starship you don't bother — heavier, simpler, more-margin, more-consumables modules are fine. Realistically that's a ~2× growth in design mass (stage-1 ~3 t → ~6–15 t; stage-2 ~6 → ~15–30 t; stage-3 ~10 → ~20–40 t).

2. The launch line collapses even as mass doubles. Approximate $/kg: Falcon 9 ~$3.0k, Falcon Heavy ~$1.5k, Starship ~$0.5k credible-early, ~$0.15k aspirational. For the Phase-1 full fleet (see phase1.py / fleet.py):

So doubling module mass and switching to Starship still cuts the launch line (from ~$0.24B to ~$0.08B) — and the whole Phase-1 fleet fits in 1–2 Starship flights instead of 5–10 Falcon 9s. Launch goes from ~6–8% of the program to ~1–2%.

3. Volume unlocks capability. Starship's ~8 m bay / ~1000 m³ means a stage-1 "Connect" can be a real shirt-sleeve refuge for a crew for days, not a phone-booth capsule jammed into a 5 m fairing. The dormant-cache concept (note 07) gets roomier consumables and shielding for free.

What it does NOT change

• The reachability math. Δv budgets, the phasing time-floor, the coverage map, the fleet counts and placement (notes 08–11) are all mass-invariant — a 3 t or 15 t responder both need the same 400 m/s; the heavier one just carries proportionally more propellant (rows above). So the coverage figures and the number of modules per plane don't move.
• The dominant program costs. Development + unit production are mass- insensitive (they're avionics, life support, heat shield, software). Launch was always the small line. So the program total stays ~$1–3B order-of-magnitude; Starship mostly buys more capable hardware and far simpler logistics for the same money, not a cheaper bill.

How many lifeboats per Starship launch?

Packing is the binding question, and it's mass OR volume, whichever runs out first (fleet.lifeboats_per_launch). Starship ≈ 100 t (credible early) to LEO and ~1000 m³ usable bay. Three representative recovery-vehicle designs:

So a single Starship lofts ~12 standing refuges, or ~4 full bring-them-home reentry vehicles, or ~33 compact pods. Refuges and reentry vehicles are mass- limited (dense — heat shield, tanks); only the lightest compact pod ever becomes volume-limited.

The headline: the entire current human population in orbit is 10 (ISS 7 + Tiangong 3). One Starship of reentry lifeboats = ~24 seats home — 2.4× the people currently in space. Everyone in orbit could be given a dedicated ride home, with margin, in a single launch. The whole Phase-1 network (notes 12) is 1–2 Starship flights.

Bottom line

Starship doesn't make the lifeboats lighter — it makes them heavier on purpose, cheaper to loft, roomier, and deliverable in one or two flights. The mass goes up, the launch cost goes down, the orbital mechanics stay put. And one Starship can carry more lifeboat seats than there are people in orbit. Plug a different LAUNCHERS[...] / LIFEBOATS[...] entry into the model and watch the counts move.

15 — Phase 2: Artemis & cislunar space

Phase 1 (notes 12) covered what's crewed today — LEO stations. Phase 2 is the next human presence beyond LEO: NASA's Artemis program. And the architecture just changed under us, which changes the rescue problem.

What Artemis actually is now (verified May 2026)

The program was restructured in February–March 2026, so the cislunar picture is different from what notes 08–09 assumed:

Correction to earlier notes. Notes 01, 02, 08, and 09 treated NRHO / Gateway as the standing crewed cislunar node. With Gateway shelved, that's no longer true: NRHO is now just a staging orbit for landers, not a place with people permanently in it. The orbital-mechanics analysis in those notes still holds (NRHO is still a real, nearly-stable orbit); only the "infrastructure / people are already there" premise is retired. This note supersedes it.

What that does to the rescue problem

There is no station to park lifeboats next to. In Phase 2 the human presence in cislunar space is transient — crews are out there only during Artemis mission windows, until a surface base appears (~Artemis V). So Phase 2 is not a standing-coverage problem; it's an event-driven one (note 11): you surge guardians for each scheduled crewed flight and stand down between them.

And the physics is the unforgiving regime (note 09):

• Phasing rescue is impossible. Cislunar periods are days (NRHO ~6.5), so a co-orbital responder can't phase to a casualty inside any survival clock. Anything that helps must be formation-flying / co-located from the start.
• No atmospheric decay to bring a crippled ship home — the free LEO lifeboat is gone.
• Deep gravity wells and big Δv gaps mean a stranded crew's reachable set is tiny and nothing slow can get to them.

So Phase 2 leans entirely on the two cheapest tools we found: trajectory-as- lifeboat (note 04 §E) and pre-positioning at the scheduled burns (note 11).

The high-exposure moments to guard

Map the mission to its irreversible, predictable, catastrophic-on-failure events — those are where pre-positioned guardians earn their keep (note 11 geometry):

The bright spot: because Orion's transit uses free-return geometry, the long, scary cruise leg is mostly self-rescuing for free. The hardware burden concentrates on lunar-vicinity operations (LOI, descent/ascent), which are exactly the events you can pre-position for.

Surface base (Artemis V+) and beyond

Once a surface base exists (~2028+), the pattern shifts to surface caches at the lunar south pole — ice → water → O₂/H₂ (the base-annex pattern, notes 02/08). And the mass-driver delivery idea (note 14 hook) becomes real only here: a base with a mass driver can fling prepared emergency modules — including would-be-boiloff propellant — fast to a cislunar casualty, attacking the time budget by launch speed. That's Phase 3.

Sizing Phase 2 (structural, not computed)

Quantitative cislunar reachability needs a three-body (CR3BP) model, which the toolkit doesn't have yet (flagged in note 13). So this is structural:

• Per crewed Artemis flight, a surge package of pre-positioned, expendable guardians: a no-burn guardian on the free-return path, a formation lifeboat shadowing Orion, and — for landing missions — a low-lunar-orbit abort refuge plus a descent-abort guardian. Call it a handful of stage-1s + one reentry- capable recovery vehicle staged in cislunar.
• That fits comfortably in well under one Starship launch (note 14: ~12 refuges or ~4 reentry lifeboats per flight). So the launch side of Phase 2 is one flight per Artemis window; the cost is in the cislunar-rated hardware and the CR3BP trajectory design, not the lift.

Honest caveats

• The schedule is fluid. Artemis has slipped repeatedly and the Feb–Mar 2026 restructuring (Gateway shelved, Artemis III re-scoped) is recent — treat dates as soft.
• The numbers here are structural, not computed — a CR3BP reachability module is the prerequisite for real cislunar Δv/time figures, and it's the clear next build (note 13).

Sources (Artemis status, May 2026)

• Artemis II — Wikipedia
• Artemis III — Wikipedia
• Artemis program — Wikipedia
• NASA Outlines Preliminary Artemis III Mission Plans — NASA

All figures