# 7GC Mission Control — model 1.1.0

Scenario `LUNAR-24`. Authored November 15, 2026 for gunnchOS. This is a deterministic educational model of a fictional outpost, not flight software, a validated habitat design or a medical model. The exercise lasts 24 Earth hours; it is not a lunar solar day.

## Traceable reference inputs

Static NASA engineering references were accessed November 15, 2026. There is no live telemetry, DONKI feed or API credential.

| Quantity | Value in the model | Source and scope |
| --- | --- | --- |
| Metabolic oxygen | 0.84 kg/person/day | Lynch et al. (2023), NASA NTRS 20230012635, Table 8, printed p. 9; **surface**, 82 kg reference crew. |
| Drinking water | 2.00 kg/person/day | Same Table 8, printed p. 10, surface column. |
| Food rehydration water | 0.50 kg/person/day | Same Table 8. |
| Hygiene / flush water | 0.40 / 0.30 kg/person/day | Same Table 8. Total modeled crew water demand is 3.20 kg/person/day. |
| Dry food stock allocation | 0.98 kg/person/day | Same paper, Table 2, printed p. 5, non-EVA **dry food as shipped**. This excludes the food’s shipped water, packaging and overwrap bags. It is not the 2.39 kg total delivered logistics rate. |
| Electrolysis feedwater | 1.125 kg H₂O/kg O₂ | Rounded stoichiometry: 2 H₂O → 2 H₂ + O₂, mass ratio 36/32; consistent with Table 11, printed p. 13. |
| Water treatment efficiency | 90% of treated wastewater | Authored plant setting informed by the historical NASA ECLSS overview updated April 4, 2025. It is not a claim about every current NASA recovery system or a lunar installation. |

Canonical sources:

- [NASA NTRS 20230012635: Logistics Rates and Assumptions for Future Human Spaceflight Missions Beyond LEO](https://ntrs.nasa.gov/citations/20230012635)
- [Full paper](https://ntrs.nasa.gov/api/citations/20230012635/downloads/Logistics%20Rates%20and%20Assumptions%20Beyond%20LEO%20V5.pdf)
- [NASA Environmental Control and Life Support Systems](https://www.nasa.gov/reference/environmental-control-and-life-support-systems-eclss/)
- [Selected challenge: Build a Junior Astronaut Mission Trainer](https://www.spaceappschallenge.org/2026/challenges/junior-astronaut-mission-trainer/)

The paper provides conceptual planning estimates, not operational program requirements. Actual metabolic needs depend on crew and activity. `data-provenance.json` identifies sourced facts, derivations, authored quantities and AI assistance. No NASA media or logo is reused.

## Authored scenario parameters

Everything below is a teaching assumption. None is presented as a measured NASA hardware specification.

| Parameter | Value |
| --- | --- |
| Crew / fixed interval / horizon | 2 / 1 h / 24 h |
| Initial / maximum battery energy | 8 / 12 kWh |
| Initial / maximum usable oxygen | 1.05 / 2.40 kg |
| Initial / maximum clean water | 8 / 12 kg |
| Initial / maximum wastewater | 0.50 / 6 kg |
| Initial / maximum dry food | 3 / 4 kg |
| Nominal / fault solar power | 2.40 / 0.65 kW, multiplied by the scenario solar factor |
| Essential habitat services | 0.60 kW, always demanded; represents ventilation, CO₂ removal and other essentials |
| Oxygen generation | 0.80 kW when enabled; up to 0.09 kg O₂/h |
| Water recovery | 0.45 kW; up to 0.24 kg existing wastewater/h; 90% returned to clean storage |
| Wastewater collection | 75% of actually served modeled crew water use |
| Science instruments | 0.90 kW; up to 1 science hour per powered hour, paused in shelter |
| Greenhouse care | 0.35 kW and up to 0.02 kg clean water/h; earns powered, watered crop-care hours |
| Shelter services | additional 0.15 kW; pauses science |
| Robot repair | additional 0.60 kW for 2–4 fully powered intervals, according to configuration |
| Array fault | begins at h = 6; remains until repair completes |
| Radiation drill | occupies [10,14); exposed 18 points/h, sheltered 0.5 points/h |
| Mission exposure limit | 60 cumulative illustrative points; no dose or clinical meaning |
| Simulated radio | 0.10 kW enabled, including during an outage; up to 3 MiB/h transmission |
| Science data generation | 2 MiB per science hour |
| Radio outage / local buffer | [12,18) / 16 MiB |

Greenhouse care represents food-production **demand**, not a crop-yield or nutrition model. It produces no edible food within the exercise and never replenishes the dry-food stock. Crop-care hours are an activity proxy; they do not establish plant health, viability or future yield. Stored dry food supplies the crew throughout the day.

Food rehydration water is included in the crew water demand. Shipped water inside food and metabolic water are outside this reduced model. It accounts for usable stocks and explicit transfers, not the total mass of crew, atmosphere, food chemistry and all habitat waste.

The array event is an electrical circuit fault, not atmospheric weather on the airless Moon. Repair uses a robot; no crew EVA is simulated. Solar availability is prescribed, with no terrain/illumination calculation.

## One authoritative engine, three views

`simulation.js` supplies `initial(configuration)`, `forecast(state, controls)`, `step(state, decisions)`, `run(policy, configuration)` and `replay(decisions, configuration)`. `step` is the only state transition implementation. It preserves its input and returns a new state. A terminal state cannot be advanced.

State includes configuration and parameter identity, hour, resource stocks, exposure, scientific work, greenhouse care, repair state, data ledger, controls, history and log. It uses no random number generator, wall clock, browser network response or remote AI service.

`planner.js` calls the same `run` and `step` functions. The interface’s Junior, Explorer and Engineer modes change wording and visible detail. Switching view neither advances time nor changes the state or equations. Browser tests verify this invariance.

Validation rejects unsupported versions, nonfinite or out-of-bounds inventories, mismatched hour/trace lengths, altered model constants, inconsistent data accounting, impossible active/success states, nonboolean controls and unknown decision keys. This is input/state validation, not cryptographic authentication of an uploaded trace.

## Interval order and equations

Decisions apply at the start of [h,h+1). Environment and loads are sampled for that interval. The model integrates the flows, updates repair, records the interval and advances the clock. A repair started at hour 6 in reference conditions occupies [6,7) and [7,8); restored solar power applies from [8,9). The radiation drill affects four intervals beginning at hours 10, 11, 12 and 13.

Let Δt = 1 h, N = 2, B = stored energy in kWh, O = usable O₂ in kg, W = clean water in kg, X = wastewater in kg, F = dry food in kg. Binary control I is 1 when enabled. `c` is the crew-consumption factor.

```
O₂ demand = N × 0.84 / 24 × c × Δt                     kg
Crew water demand = N × 3.20 / 24 × c × Δt             kg
Dry food demand = N × 0.98 / 24 × c × Δt               kg

Load = 0.60 + 0.80 I_O2 + 0.45 I_recovery
       + 0.90 I_science_and_not_sheltered
       + 0.15 I_shelter + 0.35 I_greenhouse
       + 0.10 I_radio + 0.60 I_repair                   kW

B_raw = B + (solar − load) × Δt                       kWh
Power fraction = min(1, (B + solar × Δt)/(load × Δt))
Unserved energy = max(0, load × Δt − B − solar × Δt)    kWh
Curtailed energy = max(0, B_raw − 12)                  kWh
B_next = clamp(B_raw, 0, 12)

Waste treated = I_recovery × min(0.24 × Δt, X)
                × power fraction                     kg
Water recovered = 0.90 × waste treated                kg
Crew water served = min(crew water demand, W + recovered)
Water after crew = max(0, W + recovered − crew water served)

O₂ generated = I_O2 × min(0.09 × Δt × power fraction,
                         2.40 − O + O₂ demand,
                         water after crew / 1.125)     kg
O₂ served = min(O₂ demand, O + O₂ generated)            kg
Greenhouse request = I_greenhouse × 0.02 × Δt × power fraction
Greenhouse water = min(request,
                       max(0, water after crew − 1.125 × O₂ generated))
Dry food served = min(dry food demand, F)

W_next = W + recovered − crew water served
         − 1.125 × O₂ generated − greenhouse water
O_next = O + O₂ generated − O₂ served
F_next = F − dry food served
X_next = clamp(X − waste treated + 0.75 × crew water served, 0, 6)
```

The authored allocation order under scarce clean water is crew water, oxygen-generation feedwater, then greenhouse water. Production/care cannot consume water that does not exist. Crew water, oxygen and food histories distinguish **actual served mass**, requested demand and unmet demand. Treatment reject, uncollected water, wastewater overflow and vented electrolysis hydrogen appear explicitly in the trace.

Newly collected wastewater enters X at interval end and cannot be processed in that same interval. Treatment reject, overflow, uncollected water and vented hydrogen leave modeled usable stocks. No Sabatier recovery or metabolic water is credited. Binary equipment loads remain fixed when enabled; the model does not estimate dynamic electrical efficiency during production throttling.

Science accrues in powered hours with instruments enabled and crew out of shelter. Greenhouse care accrues only to the extent its power and water requests are supplied. Exposure increments during the drill only. Stored quantities and trace flows are rounded to nine decimal places.

The power fraction is a uniform bookkeeping approximation for the terminal shortfall interval, not a sub-hour electrical dispatch model. Any unserved essential electrical demand fails the mission at interval end, using a 1e-8 kWh tolerance. Exhausting usable O₂, clean water or dry food, or reaching the exposure limit, also ends the mission. Food exhaustion is a logistics failure rule, not a claim that a crew medically starves within an hour. The reason priority is power, oxygen, water, food, exposure. Failure timestamps are interval ends, not sub-hour medical predictions.

B may reach exactly zero after fully serving a step. The mission can continue if the next interval’s generation serves its load. A zero battery is therefore distinct from unserved power. Success means completing 24 hours without an earlier terminal violation; it does not imply that the planner’s extra reserve margins are met.

## Simulated communications ledger

For each interval:

```
New data = science hours × 2 MiB/h
Available data = previous buffer + new data
Delivered = radio enabled AND link available
            ? min(available data, 3 MiB/h × Δt × power fraction) : 0
Dropped = max(0, available data − delivered − 16 MiB)
New buffer = min(16 MiB, available data − delivered)
Cumulative generated = delivered + buffered + dropped
```

New data may be transmitted during the same interval. This is an aggregate queue, not a packet simulator. It models no propagation delay, RF link budget, coding, interference, orbital relay geometry or lunar 6G network. The mission radio and the website’s offline cache are separate layers.

## Bounded comparative planning

The search tests **567 phase-policy specifications**:

- Repair starts at hour 6, 7 or 8.
- Split science allocates a target of 0–16 hours to [0,6) then [14,24).
- Late science allocates a target of 1–10 hours beginning at hour 14.
- Greenhouse care is enabled from mission start for a target of 0, 4, 8, 12, 16, 20 or 24 hours.
- All search policies retain oxygen generation, water recovery and radio power, and shelter during [10,14).

Count: (17 split targets + 10 late targets) × 3 repair choices × 7 greenhouse targets = 567. Late targets beyond the ten available hours, and the duplicate zero-science late schedule, are excluded. Different policies may still share outcomes or terminate before a differing future action.

The search is exhaustive within that family. It does not optimize every possible hourly control sequence; for example, a radio duty-cycle policy lies outside this grid. It makes no global-optimality claim.

A policy is **reserve-feasible** if it completes the mission and, throughout its completed trajectory, retains at least 0.50 kWh energy, 0.30 kg O₂, 1.00 kg clean water and 0.25 kg dry food, with at most 5 illustrative exposure points. These are authored teaching margins, not NASA operating requirements.

For reference conditions, 199 specifications meet those margins. Five science/crop-care points are nondominated: no other feasible candidate increases one of those objectives without reducing the other. For equal objective pairs, the representative with the higher minimum battery reserve is retained.

Recommendations express an explicit preference:

- Science: maximize science hours, then crop care, then minimum battery reserve.
- Greenhouse: maximize crop-care hours, then science, then minimum battery reserve.
- Balanced: among nondominated candidates, maximize min(science/16, crop care/24); ties prefer crop care, minimum battery reserve, then science.
- Reserves: maximize minimum battery reserve, then science and crop care.
- Tested-condition robustness: apply the balanced preference among candidates that meet the same margins in every sensitivity case.

Stable policy IDs break remaining ties. A recommendation is conditional on those preferences, search bounds and assumptions; it is not a universally best mission plan. `planning-evidence.json` contains every evaluated result, constraint check, selected policy and source-file digest. The browser computes its comparison from the engine, rather than loading that evidence snapshot as its answer.

## Sensitivity and uncertainty

A selected fixed policy is rerun under reference conditions, 10% less solar generation, 10% higher crew oxygen/water/food demand, one additional repair hour, and all three perturbations together. Controls are not retuned to pass a case. With a nonreference base configuration, changes are relative to that base and capped at supported limits.

The input schema permits solar factors 0.5–1.2, crew factors 0.8–1.3 and integer repair durations 2–4 h. The UI provides five named configurations. In reference conditions, 18 of the 567 specifications meet reserve requirements in all five sensitivity cases. Passing these cases provides bounded deterministic evidence, not a probability of success or robustness over all possible disturbances.

A severe but valid configuration can yield no feasible candidate. The engine/planner report that outcome explicitly instead of inventing a successful plan.

## Architecture and reproducibility

- `simulation.js`: pure transition, forecast, validation, configurations, replay.
- `planner.js`: phase-policy generator, full engine evaluations, constraints, Pareto filtering, preference ranking and sensitivity.
- `app.js`: shared-state Junior/Explorer/Engineer views, controls, dictionary, actual planner results, trace and record exports.
- `index.html`, `styles.css`: semantic controls and original AI-generated code-native schematic; no external runtime libraries or fonts.
- `sw.js`: same-origin cached application resources for offline reload after first load.
- `offline.html`: generated self-contained playable app, including planner and explanations; opens directly from file://.
- `tools/generate-evidence.cjs`: static reference records/report from the current engine and source digests.
- `tools/verify-record.cjs`: exact replay verification with matching model version, configuration and parameters.
- `tests/`: substantive model, planning and real-browser checks.

The committed source release and exported records identify model 1.1.0. Baseline model 1.0.0 remains in its archived source/deployment for rollback. Use the matching source release to replay an older record.

## Limits and legitimate next research

No cabin gas partial pressures, explicit CO₂ accumulation, heat balance, battery aging/efficiency/rate limits, treatment chemistry, plant growth/yield, radiation transport, full habitat mass closure or physically derived communications link. The source rates describe reference planning cases, not this fictional hardware.

Next work should begin with educator and learner feedback, reading-level assessment and assistive-technology testing. Engineering extensions could replace the phase family with constrained scheduling, validate load/production models, add crop biology and thermal/CO₂ states, and derive a communications service curve from a documented link model. These are future research directions, not delivered capabilities or validated learning results.