NASA's Artemis crew selection runs on this stack

NASA named its Artemis II and III crew candidates this week. Cool. Here's what the engineering behind astronaut selection and mission systems actually looks like, because nobody talks about this and it's genuinely wild.

The selection pipeline is messier than your microservices

Astronaut selection runs on a combination of JSC's internal systems and, yes, off-the-shelf tooling you've used. Medical records processing through HL7 FHIR interfaces. Psychometric test scoring pipelines that batch-process structured assessment outputs into candidate profiles stored in PostgreSQL clusters running on-prem at Johnson Space Center. These aren't glamorous systems. They're government procurement systems built in 2011 that someone patched in 2019 and is now too scared to touch.

I've seen this pattern kill production at smaller stakes. In 2021 at a 600-person fintech I consulted for, their compliance team was running candidate background checks through a vendor API that returned inconsistent JSON schemas across versions. Nobody noticed for eight months. Cost them $340k in manual remediation when an audit hit. NASA's equivalent is the Astronaut Selection Board software stack, and I'd bet my Datadog bill it has the same versioning problem.

The actual interesting part: mission simulation compute

Here's the thing. The crew selection announcement is the press release. The real engineering is what happens after.

Artemis mission planning runs through NASA's GMAT — General Mission Analysis Tool — which is open source, written in C++, and genuinely excellent. Go read the source. It's one of the better-architected codebases in aerospace. Orbital mechanics simulations for a lunar trajectory generate on the order of terabytes of state vector data per planning cycle. That data feeds into Trick, NASA's simulation framework, also open source, which orchestrates the variable-timestep simulation environment the crew trains against.

The latency requirements here are brutal. Real-time crew training simulations need sub-20ms response on physics state updates. They're running this on dedicated SGI-origin hardware clusters at JSC, not AWS. Don't do this on commodity cloud if lives are on the line. The egress costs alone would be obscene, but more importantly, you don't want a noisy neighbor event during a docking simulation.

What AI actually does in this stack

Everyone's asking how AI fits into NASA mission planning now. The honest answer: narrow and specific.

NASA's LOLA dataset — Lunar Orbiter Laser Altimeter — is 6.8 billion elevation points on the lunar surface. ML models trained on this data do terrain hazard classification for landing site selection. Not GPT. Convolutional nets running on labeled topographic features, outputting slope-angle risk scores that feed into the human-reviewed landing zone database. The model doesn't pick the landing site. It eliminates the obvious bad ones so humans aren't manually reviewing 40 million candidates.

For crew biometric monitoring during training, they're using LSTM-based anomaly detection on physiological time series. Heart rate variability, blood oxygen, vestibular response data. The model flags deviations. A flight surgeon makes the call. That's the right architecture. The AI is a filter, not a decision-maker.

The pattern that works: ML eliminates the clearly wrong options at scale. Humans decide among the remaining good ones. Anyone shipping AI that inverts this has either never been on-call or doesn't care about what breaks at 3am.

What's going to break

Artemis III is targeting 2026. The surface EVA systems depend on real-time telemetry from suits that run VxWorks, synced to ground systems over TDRS relay with 1.3 second one-way latency to the Moon. Building distributed systems that handle that latency gracefully is a hard problem. It's the same class of problem as globally distributed databases with consistency requirements, except the partition can't be resolved by spinning up another region. There's only one Moon region and it doesn't have an SLA.

I'd start thinking about that now if I were on that team.