Lab Module A

A two-world supply chain game where the Moon is not harder Texas.

▶ Play it in your browser

No install, no account, no server. The physics engine is Python and it starts up inside your tab — about 20 MB on a first visit, then it runs offline.

---

Two teams get the same money and the same blueprint: Lab Module A, a 42-tonne research laboratory for four people. One team builds it at the lunar south pole. The other builds it in Antarctica, at McMurdo.

You run the Moon. The Earth team runs beside you the whole way, on the same clock and the same budget, and at the end you find out what the Moon actually cost — not in rhetoric, in dollars, days and kilograms of useful mass.

It takes about half an hour. Most people lose the first one.

Why it is not just a build queue

Terrestrial supply chain rests on four assumptions. The Moon breaks all four, and the game makes you feel each break rather than reading you a paragraph about it.

On Earth	On the Moon, in this game
Transport is cheap next to the goods	Mass is the currency. A $40 wrench costs $40,000 to land, and you only ever see the landed price
You can expedite	The Expedite button is on both screens. On the Moon screen it is permanently disabled, and it tells you why every time you hover it
There is a supplier market	One qualified vendor, an 18–36 month lead time, and a qualification gate that can fail you back to redesign
Demand can be forecast from fleet history	Your fleet size is 1. Spares come from physics-based failure models with error bars you can see

The punchline, and the whole reason the Earth track is on screen: on Earth a problem costs money and days. On the Moon it costs a launch window — months — and money cannot buy the window back.

None of that is this project's idea. The 2012 NSF Blue Ribbon Panel on Antarctic logistics found that fuel at the South Pole is worth, on average, close to eight times what it cost to buy, and that you cannot charter part of a ship or usefully fly a half-empty aircraft. That last one is the disabled top-up button, written by the people who pay for it.

The choice that decides your campaign

Before anything else you pick a landing site. These are three real places, and every number here is computed from LOLA laser altimetry and the DE440 ephemeris — not written to make a point:

	sunlit	skyline	peak skin temp	LOX boils?	Earth in view	longest blackout
Ridge crest	100%	−0.3°	197 K	yes	51%	8.5 days
Median terrain	44%	17.0°	198 K	yes	0%	29.5 days
Crater floor	0%	26.9°	20 K	no	0%	29.5 days

The ridge gives you continuous sun and half a month of comms, and cooks your propellant. The crater floor keeps liquid oxygen cold forever and leaves you dark and blind. Two of the three sites never see Earth at all — not for a day, not once, ever — because libration keeps Earth below 7° of elevation and their own skyline stands at 17° and 27°.

That finding came out of measuring, not assuming. The Sun sweeps all 360° of azimuth in a lunar month while the Earth holds one bearing to within about 11°, so the same terrain decides your power and your comms, and it decides them independently. A site can win one and lose the other. Nobody wrote that rule into the game; it fell out of the altimetry.

Everything on screen is computed

There is no lookup table of plausible-sounding numbers anywhere in this repo. Every quantity in the engine carries its own epistemic layer, checked in code:

• L1 — physical law. The rocket equation, the Stefan–Boltzmann balance, conservation. Exact, and tested as exact.
• L2 — empirical. Measured, cited, and carrying its uncertainty band. NIST for cryogen properties. McIntosh for multilayer insulation. LOLA for terrain. DE440 for where things are.
• L3 — programmatic. Nobody knows this number. It is a slider, it is labelled a slider in the interface, and the Sobol analysis inside the game will tell you how much it actually moves the answer.

A quantity's layer propagates by weakest link, so anything downstream of a guess is marked as downstream of a guess. Where a source could not be found, the gap is recorded as a gap rather than filled with something reasonable.

642 tests. Seven validation gates, of which the interesting ones:

• V-1a — Apollo 11 and 17 landed mass, reproduced from the propellant record. Within +0.63% and +0.72%, residual strictly positive.
• V-5 — Antarctic resupply, cross-checked against two independent reports. Amundsen–Scott costs 27.2 tonnes per person-year to run.
• V-6 — mass, propellant, money and energy balance every tick, reconciled two independent ways rather than by re-adding one counter.
• V-7 — 1,000 runs from one seed produce 1 distinct state hash.

Three gates are still BLOCKED or NOT BUILT, and docs/VALIDATION.md says exactly which and why. A gate that has not run is worth more written down than quietly dropped.

Three things that went wrong while building it

The most useful part of this repo is probably the record of its own mistakes. docs/DECISIONS.md has sixty of them. Three worth the click:

The game could not be won, and 523 tests did not notice. At a $10 billion budget over 1,200 days the campaign installed zero of twelve districts while spending $891M. Money was never the constraint. The cargo loader walked the blueprint in order, offload is eleventh in that order, and nothing can be installed until offload is — so cargo landed, piled up on the deck, and stayed there. Every test asserted things about a campaign that could not finish.

Every event charged twice, and the conservation audit could not see it. A supplier delay priced at $8M took $16M. V-6 passed the entire time, because the double charge wrote to both the counter and the log — both sides were wrong by exactly the same amount and reconciled perfectly. A conservation check proves your books are consistent, not that the price is right.

"The Earth hangs in one place in the lunar sky" is wrong at the pole. Tide-locking fixes the Earth's selenographic direction, not its elevation; libration swings it about ±7°. At the pole that is the whole difference between having a comms link and not having one, so the error became the mechanic in the table above.

How it runs with no server

The desktop build talks to a small Python server. The web build has no server, and the two usual escapes are both bad: rewrite the campaign in TypeScript, and the browser plays a different game from the one 642 tests are written against; or run it on a server, and pay for cold starts forever.

So the browser runs the actual engine — engine/campaign.py, unmodified — under Pyodide in a worker. The two things that genuinely cannot fit are handled rather than faked:

• 154 MB of SPICE kernels and LOLA altimetry. Precomputed by scripts/bake_web.py at exactly the epochs the campaign will ask for, so the browser reads the same float64 values this machine computed rather than an interpolation of them. The bake script proves that: it replays whole campaigns against real kernels and against the bake, in separate processes, and compares them turn for turn. Nine campaigns across three sites, identical — same spend, same propellant, same skin temperature, same win on the same day. Past the end of the table it raises rather than clamping, because a frozen sky looks entirely plausible.
• SciPy, 12 MB, needed only by the spares panel. Loaded when you first open that panel.

One consequence worth naming: the game loop used to call CP-SAT on every cargo launch, and OR-Tools does not exist in the browser. Rather than ship a second packer, the campaign's actual problem — one lander, no precedence — got an exact enumerating solver in engine/packing.py that both builds use. Twelve items is 4,096 subsets; a two-second solve became a millisecond, and tests/test_packing.py holds it to CP-SAT's optimum on forty random instances.

Run it yourself

uv venv --python 3.12 && uv pip install -e ".[solvers,stats,dev]"
uv run python scripts/fetch_data.py     # kernels, DEM and reference data — not vendored
uv run pytest tests/ -q
uv run python scripts/serve_game.py     # http://127.0.0.1:8766

To rebuild the public, no-server version:

uv run python scripts/release_web.py --bake

What is in here

The spec, and the design it settled into	docs/BRIEF.md, docs/GAME-LAYER.md
Every equation and where it came from	docs/PHYSICS.md
The validation gates and their residuals	docs/VALIDATION.md
Every judgement call, including the wrong ones	docs/DECISIONS.md
What is done and what is not	docs/PROGRESS.md
The three-layer rule, in code	engine/layers.py

What this is not

It is not a prediction of what a lunar base would cost. The blueprint's 42 tonnes is the brief's; the split of that mass across twelve subsystems is a scenario allocation and is tagged as one, not a sourced bill of materials. Launch price, tanker count and window cadence are L3 sliders because nobody knows them, and the interface says so on the same screen that shows you the number.

What it is: an argument that the interesting part of going to the Moon is logistics, made in a form where you can lose.

Credits

Terrain from NASA LRO/LOLA. Ephemerides from JPL DE440 via NAIF SPICE. Cryogen properties from NIST. Multilayer insulation from McIntosh. Antarctic figures from the NSF Blue Ribbon Panel (Augustine, chair, 2012). Apollo mass records from Orloff.

MIT licensed. Built by Amitendra Singh.