NASA-IBM Lunar Foundation Model Beats a Crater Baseline With Half the Labels

NASA and IBM released the NASA-IBM Lunar Foundation Model after reporting a nearly 19% crater-detection improvement with half the labeled training data. The result concerns a specific benchmark at roughly 100-meter-per-pixel resolution, not every crater-mapping task. That distinction matters because the model’s broader value depends on whether researchers can adapt one lunar data backbone to several scientific problems.

The model combines observations collected at different resolutions, viewing angles, and wavelengths. Researchers can fine-tune it for crater detection, polar ice prospectivity, and mapping unusual volcanic formations. NASA and IBM also released model weights, downstream datasets, and code for testing the system.

This is more than another image-recognition demonstration. Lunar science has accumulated large datasets from instruments that measure different physical properties at radically different scales. Scientists typically build specialized pipelines for each task, while the new model offers a reusable starting point trained on lunar observations.

That creates the central test. A domain-specific foundation model should reduce the labels, computing, and engineering needed for new studies. It must still produce scientifically reliable results across unfamiliar locations, illumination conditions, instruments, and research questions.

The NASA-IBM Lunar Foundation Model turns lunar archives into reusable infrastructure

The immediate change is that lunar researchers now have an openly available, pretrained model instead of starting each mapping project with a general vision system.

NASA announced the model on September 10, 2026, as part of its continuing AI-for-science collaboration with IBM Research. The agency describes it as one of the first open-source foundation models created specifically for lunar science.

A foundation model is trained on a broad dataset before being adapted to narrower tasks. In this case, pretraining teaches the system recurring patterns across lunar terrain and sensor measurements. Researchers can then add smaller task-specific datasets for crater detection, ice analysis, or volcanic mapping.

The model was trained primarily on observations from NASA’s Lunar Reconnaissance Orbiter, or LRO. NASA says the spacecraft has collected more data than all its other planetary missions combined during 17 years of operations.

According to the agency’s lunar model release, the training corpus contained roughly two million image tiles. That total included more than one million high-resolution camera images at one-meter resolution and nearly 964,000 multispectral images at 100-meter resolution.

Other inputs came from NASA’s GRAIL and Lunar Prospector missions, plus the Japanese space agency’s SELENE mission. These missions did not observe the Moon in identical ways.

Optical cameras record reflected light. Altimetry describes elevation, while thermal and spectral measurements capture other physical properties. Their spatial resolutions can range from about one meter per pixel to measurements spanning kilometers.

The NASA-IBM model converts these heterogeneous observations into a shared representation. That representation is the internal pattern library that downstream models can reuse.

NASA identifies three initial scientific priorities. Researchers want to catalog small craters, investigate relatively young volcanic features, and estimate where ice remains stable near the lunar poles.

Each task serves a different scientific question. Crater counts help researchers estimate surface ages. Irregular mare patches, which are unusual volcanic formations, can refine the Moon’s thermal history. Polar ice maps can guide research into lunar volatiles and inform future exploration planning.

The model also recognized a newly formed crater near Einstein crater in a before-and-after image test. The post-impact observation was excluded from pretraining, according to NASA. That makes the example a useful test of adaptation to a surface change the pretrained model had not already seen.

However, the example does not mean the system autonomously discovered an unknown impact across the entire Moon. It shows that a fine-tuned model can identify a known type of change within prepared orbital imagery.

That narrower description still represents useful progress. Automated screening can help scientists reduce a vast archive into a manageable set of candidate locations for expert review.

Why AI crater detection needs fewer labels, not just a higher score

The 19% figure matters because labeled lunar data is scarce, expensive to produce, and often dependent on specialist judgment.

Machine-learning systems need examples that connect an input image to the expected output. For crater detection, those labels describe where craters appear and how their boundaries should be represented.

Creating such annotations is not equivalent to labeling everyday photographs. Craters overlap, erode, and appear differently under changing sunlight. Small depressions can resemble shadows or other terrain structures. Resolution also determines which formations are visible enough to classify.

The NASA-IBM model enters this task with knowledge learned from a much larger body of unlabeled lunar data. It does not begin with random parameters or only the patterns learned from terrestrial photographs.

That pretraining should be especially valuable when a project has limited expert annotations. Instead of teaching a system the entire visual language of the Moon, researchers can focus their labels on the scientific target.

IBM says the model used low-rank adaptation, or LoRA, for downstream tasks. LoRA adjusts a relatively small set of parameters while keeping most of the pretrained model unchanged. The company reports that 90% of the base weights remained frozen during adaptation.

This technique lowers the amount of computing and task-specific training required. It also provides a practical route for research groups that cannot train a large vision model from scratch.

The released crater checkpoint uses the pretrained lunar backbone with a Faster R-CNN detection head. Faster R-CNN is an object-detection architecture that proposes likely regions and then classifies their contents.

At the broader context scale, the checkpoint works with Wide Angle Camera imagery at approximately 100 meters per pixel. Its benchmark contains tiles associated with a manually annotated catalog of more than two million lunar impact craters.

The public crater model card reports results across five random seeds. The published evaluations kept dataset splits, augmentations, loaders, losses, and metrics fixed while changing the encoder and its initialization.

With half of the training split, the fully fine-tuned lunar model reached mean average precision of 0.2541. The ImageNet-pretrained SwinV2-B baseline reached 0.2313 under the same half-data condition.

Mean average precision, or mAP, summarizes detection quality across several overlap thresholds. A prediction must both find the object and place its bounding box sufficiently close to the labeled boundary.

The widely cited 19% improvement refers to the stricter AP@75 measurement. At half data, the lunar model scored 0.2213, compared with 0.1862 for SwinV2-B. That is an improvement of approximately 18.9%.

The comparison is legitimate, but it needs the metric attached. The improvement in overall mAP under the same half-data condition was closer to 10%.

A second comparison is arguably more consequential. With half the training data, the lunar model’s 0.2541 mAP exceeded SwinV2-B’s 0.2420 result when that baseline used the full training split.

That result supports the model’s central proposition. Domain pretraining can compensate for some missing task labels, at least on this benchmark.

The advantage was not universal across resolution levels. On the meter-scale Narrow Angle Camera dataset, the adapted lunar model scored 0.1543 mAP. SwinV2-B reached 0.1552, making the two statistically indistinguishable based on the reported variation.

The NASA lunar AI model therefore does not replace every specialized detector. Its strongest evidence concerns label efficiency and context-scale crater detection, while fine-resolution performance remains comparable to the best tested baseline.

One model now connects craters, ice, and volcanic terrain

The deeper mechanism is multimodal pretraining, which lets one backbone reuse relationships learned across several instruments and scientific targets.

A general image model normally treats an orbital image much like another visual input. It can recognize shapes and textures, but it has not necessarily learned how lunar temperature, elevation, lighting, and spectral measurements relate.

The NASA-IBM Lunar Foundation Model was designed around those relationships. IBM says its architecture derives from TerraMind, an Earth-observation foundation model developed with the European Space Agency.

The lunar version was trained across more than 30 spatially aligned layers from multiple instruments. Alignment means the model can associate measurements describing the same location, even when their original scales and formats differ.

That is important near the lunar poles. A dark region in a visible image does not automatically contain water ice. It might simply face away from the Sun during that observation.

An ice-prospectivity model must examine several connected properties. These include maximum surface temperature, slope, terrain orientation, radar information, and estimates of how deeply ice could remain stable.

IBM reports that the model reduced error by 22% against a SwinV2-based system in its polar ice task. The reported benefit came from combining modalities rather than asking a visible-light model to infer subsurface conditions from appearance alone.

The model also retained useful predictions when researchers removed some input channels. That behavior matters because planetary datasets are rarely complete and uniform. A future investigation might lack one measurement type for a particular region.

Ice prospectivity is still a model estimate, not direct confirmation of an accessible deposit. NASA’s wording is careful: the system estimates where ice patches are likely to remain stable on or below the surface.

Confirmation requires observations from other instruments or measurements taken at the location. Concentration, depth, contamination, and extraction difficulty remain separate questions.

The third demonstrated task concerns irregular mare patches. These formations appear smoother and younger than much of the surrounding terrain. Their apparent age has prompted questions about how long lunar volcanic activity persisted.

In the reported evaluation, the model’s segmentation result exceeded a task-specific Swin baseline by about 3%. Segmentation assigns terrain pixels to a target class, rather than drawing a box around an object.

The gain is smaller than the crater headline, but the task broadens the model’s significance. One pretrained backbone handled detection, segmentation, and continuous-value prediction across different lunar science problems.

That flexibility pressures the task-by-task development route. Under that older approach, a research team selects an architecture, assembles labels, trains a model, and maintains a custom pipeline for one question.

A reusable lunar backbone moves much of that work into a shared layer. New studies still need domain knowledge, appropriate labels, evaluation, and interpretation. They do not necessarily need to relearn the Moon’s basic statistical patterns.

NASA and IBM previously followed this strategy with Earth-observation and solar models. Prithvi models support geospatial applications, while Surya targets heliophysics tasks such as space-weather prediction.

The lunar release extends that model family beyond Earth and the Sun. It also tests whether scientific foundation models can become shared research infrastructure rather than isolated demonstrations.

IBM’s detailed model overview calls the current release a first pass. That description is appropriate. Reusability is the proposition being tested, not a settled outcome.

The 19% result does not settle scientific reliability

The main uncertainty is whether benchmark efficiency survives new regions, different observation conditions, and research questions that were not represented during evaluation.

The crater result comes from curated datasets with fixed splits and known annotations. Real investigations introduce complications that a benchmark may not capture.

Lighting is one example. Lunar surface images can change dramatically with solar incidence angle. Shadows reveal topography under some conditions but hide smaller features under others.

NASA acknowledges that different lighting conditions between orbital passes can affect the visibility of small craters. A change detector might therefore confuse illumination differences with a physical surface change.

The benchmark itself limits lighting variation for some context-scale tiles. This makes comparisons between models cleaner, but it does not fully represent every orbital image a production system could encounter.

Label quality presents another issue. Human-generated crater catalogs are valuable reference sets, yet they are not perfect descriptions of physical reality. Experts can disagree about degraded rims, overlapping impacts, and the minimum diameter that qualifies as a crater.

A model optimized against those labels learns their conventions and omissions. Higher average precision means better agreement with the benchmark, not an independent confirmation that every prediction is scientifically correct.

Geographic leakage also deserves scrutiny. The model was pretrained on broad LRO coverage, then fine-tuned and evaluated on downstream lunar data. Researchers need to determine whether the learned advantage transfers to geologically distinct regions, instruments, and acquisition conditions.

This is not necessarily a flaw. Foundation models are supposed to reuse broad pretraining knowledge. However, strong validation should separate useful generalization from familiarity with the wider data distribution.

The public release improves the prospects for such testing. NASA and IBM made the model weights, benchmark datasets, fine-tuning configurations, and downstream checkpoints available under an Apache 2.0 license.

The released codebase supports fine-tuning and inference through TerraTorch. It includes configurations for crater detection, volcanic-patch segmentation, and ice prospectivity.

However, the repository states that pretraining code is not included. That means outside researchers can inspect and reproduce downstream adaptation more easily than they can recreate the original pretraining process.

Open weights are still materially more useful than an inaccessible service. Scientists can run controlled evaluations, examine failure cases, change the detection threshold, and compare the backbone with other systems.

Yet open science also depends on documentation of data preparation, model construction, and training decisions. Releasing additional pretraining details would strengthen reproducibility and help other institutions adapt the approach to Mars, asteroids, or new lunar instruments.

Another limitation concerns operational claims. The model can inform crater mapping or ice research, but NASA has not presented it as a certified navigation or landing-safety system.

Mission decisions require verified terrain products, uncertainty estimates, and engineering review. A research checkpoint that performs well on held-out imagery is not automatically suitable for controlling a spacecraft.

The same caution applies to resource planning. Ice-prospectivity maps can rank locations for further study. They cannot establish how much extractable water exists at a site or whether an exploration system can reach it safely.

The best reading of the evidence is therefore specific. The model has produced strong initial results across several benchmark tasks, with a notable label-efficiency advantage in context-scale crater detection. Independent replication and field-oriented validation must determine its practical scientific reach.

Open access puts specialized lunar models under pressure

NASA and IBM are pressuring the custom-model route by giving researchers a common backbone, datasets, and runnable task configurations.

The primary competition is not NASA against another space agency or IBM against another technology company. It is a technical choice between reusable domain pretraining and separate models built for individual tasks.

General computer-vision systems remain relevant to that comparison. SwinV2-B, one of the principal baselines, is a hierarchical vision transformer initially pretrained on ordinary image datasets.

Those models benefit from mature tooling and extensive testing. They can also perform well on lunar tasks after fine-tuning, as the meter-scale crater result demonstrates.

The lunar model’s advantage is prior exposure to the target domain. Its pretraining data includes the textures, scales, sensor channels, and terrain relationships that a terrestrial image model must learn during adaptation.

That advantage becomes most valuable when labels are scarce. The reported half-data result suggests a small research team can approach or exceed a general model’s full-data performance without annotating as many examples.

The economics differ from commercial generative AI. The relevant cost is not only accelerator time. Planetary scientists must define labels, resolve ambiguous examples, prepare spatial datasets, and validate outputs against scientific knowledge.

Reducing that work can shorten an experiment. It can also make specialized analysis available to teams that have strong scientific expertise but limited machine-learning infrastructure.

Open distribution further changes the balance. The model and downstream checkpoints are available through the public model collection, rather than behind a proprietary application interface.

Researchers can fine-tune locally, inspect configurations, and compare results on their own data. They can also publish failure analyses without depending on a vendor’s hosted service.

This approach aligns with NASA’s broader open-science goals. Publicly funded observations gain additional value when outside institutions can build on reusable representations instead of repeatedly cleaning the same archives.

The release also creates pressure for better benchmarks. Once the community shares a backbone, disagreements can move toward evaluation design, uncertainty, and scientific usefulness.

Future comparisons should test unfamiliar geographic regions, altered sensor combinations, and temporal changes. They should also measure calibration, which asks whether the model’s confidence accurately reflects its error rate.

Operational users will need more than a leaderboard result. They must know when the model is uncertain, which input channel drove a prediction, and how performance changes when observations are missing or degraded.

Academic teams can now investigate those questions using the released artifacts. Their findings will decide whether this project becomes durable infrastructure or remains an impressive collection of task demonstrations.

Three signals will show whether lunar AI moves beyond benchmarks

The next stage is community verification, followed by evidence that the same backbone can support new science without extensive retraining.

The first signal is independent benchmark reproduction. External teams should be able to recover comparable crater, ice, and volcanic-mapping results from the released weights, data, and configurations.

This test will clarify the meaning of the 19% figure. It should preserve the distinction between AP@75, overall mAP, half-data performance, and the separate meter-scale evaluation.

Reproduction would strengthen confidence in the engineering claims. Significant unexplained differences would weaken the case for using the model as a common scientific baseline.

The second signal is transfer to unfamiliar data. Researchers should test regions, observation geometries, instruments, or targets that differ from the released downstream benchmarks.

A convincing result would show that the NASA-IBM Lunar Foundation Model reduces labeling requirements on a task selected after pretraining. That would support the claim that it learned broadly reusable lunar representations.

Poor transfer would suggest the current gains depend heavily on the training distribution. The model could still be useful, but its role would look more like a strong specialized backbone than general lunar infrastructure.

The third signal is adoption within published research or mission-planning workflows. Scientists need to show that the model changes an actual analytical process, not only its benchmark score.

Useful evidence might include a new crater catalog, a prioritized set of polar observations, or a volcanic map that experts validate against independent measurements. A mission team could also document how model outputs reduced manual screening without bypassing scientific review.

NASA and IBM should publish failure cases alongside successful applications. Lighting artifacts, missing channels, unusual terrain, and ambiguous labels can reveal where human judgment remains essential.

Developers should watch the project for another reason. The release offers a concrete test of domain foundation models outside language generation. Its central question applies across medicine, climate science, manufacturing, and remote sensing: can broad unlabeled pretraining reduce the expensive labels needed for specialized work?

Researchers can begin with the technical report, examine the model cards, and reproduce one downstream task before adding new data. The most valuable contribution may not be a higher score. It may be a carefully documented case where the lunar model fails.

Will independent teams confirm its label-efficiency advantage, then extend it to observations and questions NASA and IBM did not choose? That is the standard the NASA-IBM Lunar Foundation Model must meet before a promising benchmark becomes dependable scientific infrastructure.