Andy Garcia · freelance dev
FRENES
Back to the blog
Science & Data

NASA Released 800 GB of Artemis II Moon Data. The Crew Recordings It Ranked First Weigh 0.7 GB.

October 19, 2026 7 min read

On Wednesday, October 7, NASA released what it calls the full lunar science dataset from Artemis II, the crewed flight that swung around the Moon on April 6. More than 800 gigabytes went into the Planetary Data System, NASA's public archive for planetary missions: more than 11,000 full-resolution images and videos from the crew's handheld cameras and Orion's cameras, 8.5 hours of audio of the crew describing the lunar surface, and crew-annotated images. NASA calls it "the first planetary science dataset captured primarily by humans in more than half a century."

Headlines went to the 800 gigabytes, the pictures and the five impact flashes. I went to the paperwork. Three documents shipped with the data: a Preliminary Lunar Science Report (134 pages), a Lunar Science Operations Report (54 pages) and a Lunar Science Data User Guide (63 pages).

I am CTO of a LegalTech built on Claude, and I built BidForge, an AI that reads French public tender files for small businesses. Both live on document bundles someone else assembled. A bundle without a guide is a pile. This one reads like a template for anyone who ships a dataset, an export or an API.

A package, with a deadline and a reviewer

The release was not squeezed in after the fact. The preliminary report says NASA Headquarters required four publications from the Lunar Science Team within six months of the mission, alongside the archive: the two reports, the user guide and an open science and data management plan. Splashdown came at 00:07 UTC on April 11. October 7 is 179 days later.

The user guide has a change log. Version 1.0-PR was submitted for PDS peer review on July 20, a revised delivery followed on September 25, and version 1.0 went out with the data. PDS peer reviewers read the guide and the archive before the public did, and the acknowledgements name them.

Every bundle has a DOI and a ready-made citation. The record for the crew camera bundle lists the four astronauts among its authors. The guide gives contact addresses, a link to a search API for programmatic access, and a warning that its own URLs "are not immutable and may change in the future."

Value is not volume

The operations report has a table of everything the science team received: 11,591 files, 814.51 GB. Of that, 598.20 GB is 22 video files from one camera on a solar array wing, recorded on the ground in a broadcast format. The guide adds that converting them to MP4 for the archive shrank them substantially.

The data the team ranked first is the audio the crew recorded on their tablets during the flyby. All the tablet audio the team received comes to 53 files and 0.70 GB. The operations report gives two reasons for the ranking. Those recordings could inform the next day's science conference with the crew, and the tablets were more susceptible to radiation damage than the camera cards. The preliminary report adds that no backup existed.

Optical communications worked, at about 60 Mbps against about 2 Mbps on S-band, and the team received almost 114 GB during the mission. But the priority list was written before launch, for the case where that bandwidth never came.

That is the first habit I would copy: rank data by what you cannot recreate and what the next decision needs, not by size.

The limits are on the page

The guide does not oversell. The cameras were off the shelf. The only pre-flight characterization was a lens distortion model for the two Nikon D5 cameras, no color calibration was done, and "no calibration has been applied" to the archived images. The preliminary report says images taken by different cameras at the same moment "should not be used for direct quantitative comparison of surface properties."

It lists the traps a user would otherwise find alone. NASA ID numbers follow the order in which files were received and catalogued, not necessarily the order in which they were taken; to sort by time, read the start_date_time field. Docking camera times are best estimates that "may be offset by up to 5 minutes or more." The tablet audio files embed the time a recording ended, not when it started. For parts of the flyby, including the eclipse, the live video dropped to 5 frames per second for lack of bandwidth, and the missing frames were never recorded.

It also says what is missing. The iPhone images were still being prepared when the guide was written. On October 19, the PDS Geosciences page still described the navigation (SPICE) bundle as delayed.

Plenty of software teams have an ID-versus-timestamp bug in their history. This guide defuses it in one paragraph.

The machines did the first pass, and the guide says so

Two kinds of content in the archive come from models, and both are labeled.

The transcripts were generated with whisperX, an open-source speech recognition package, using the large-v2 model, then checked and corrected by the team. The guide names the common errors (misspelled lunar features and crew names) and says speaker labels were added by hand. A note warns that line breaks come from speech pattern recognition, "not by humans."

The image locations come from a retrieval pipeline any AI engineer will recognize. A lunar basemap was tiled and embedded into a vector database; each crew photo was embedded with the same model, the closest tiles were retrieved, then matched point by point. Control points exist for 3,687 Nikon images of the Moon, out of 10,339 Nikon images in all. The preliminary report says only about 30 percent of crew images could be georeferenced, and gives three reasons: the affine transform assumption, harsh lighting, and a lunar disk too small in wide shots. The counts do not quite agree across the documents: the footprint map in the same report covers 3,687 images (about 35 percent), the one in the guide covers 3,101 (about 30 percent). The guide flags the precision lost by matching on downsampled images and keeps the raw control points for anyone who wants to redo the transform.

I fact-check my own posts with a model as a judge, and its flags still get a second read before anything goes out. Same pattern here, with one difference that matters for a public dataset: the corrections are documented.

A shutter click as a clock

The most practical paragraph is about time. To link what an astronaut said with the photo she took, the team used timestamps and, as an extra cue, the sound of camera shutters, which the report says are "easily audible above the ambient cabin noise." The crew annotations carry no timestamp at all. They are tied to observation blocks and placed in time by listening to the audio.

The recommendations that follow apply to any product with logs from several devices: keep timestamps synchronized across every system, and record passively instead of asking busy people to press start and stop.

What the data does not show yet

The preliminary report is what its name says. It documents initial discussion of crew observations and expects the science return to "continue to expand" as others work on the data.

The five impact flashes are crew reports, made during the 54-minute eclipse. NASA says the team ruled out cosmic rays and spacecraft reflections, and that the crew "likely caught the faintest ever seen with the unaided eye," from rocks no more than a couple of inches wide. The only video recorded on board during the flyby, about two minutes at 30 frames per second, caught none, though it covered a limited period. The report says the strongest flash dataset is the count itself, and that the resulting craters are likely too small for the Lunar Reconnaissance Orbiter's camera to resolve.

The colors are another case. Because none of the images were calibrated, the report says color analysis is "necessarily qualitative," and the crew's verbal descriptions are the primary data. The report's conclusion calls the crew observations, with the Orion camera data, "the most comprehensive human-acquired orbital dataset of the Moon since Apollo." That is a claim about coverage, not a result.

What I would copy on Monday

If you ship a dataset, an export or a public API, the Artemis II guide doubles as a checklist:

  1. A versioned guide with a change log, read by someone outside the team before release.
  2. Known issues near the top: what is uncalibrated, approximate or missing.
  3. One sentence on which field orders the records, especially when IDs do not.
  4. Raw next to processed, with the exact commands used to convert (the guide prints its ffmpeg and GDAL lines).
  5. Machine-generated fields labeled, with what humans corrected.
  6. A stable identifier, a citation line and a contact address.

The photos will get the attention. The 63 pages are what make 800 GB usable.

Sources

A project like this one?

I design and deploy products like this. Let's talk.

Let's talk