Construction on the Moon? Then Let’s Talk About How It Gets Built.
Updated: Sep 11
What major infrastructure practice can teach us about delivering the first lunar construction project.
Program: Lunar Construction Delivery Campaign
Site: Lunar Construction Proving Ground
On a real project, the ground is imperfectly known, access is constrained, equipment competes for space and power, production rarely follows the nominal rate, interfaces become bottlenecks, and conditions change after work starts. Somebody has to manage that, keep the project moving, verify what was built and eventually accept the asset.
So rather than proposing another lunar testbed, I would take a different step: use the capabilities already being developed and run them as a construction project. One site. One defined civil asset. Real ground uncertainty. A construction method, production basis, power budget, schedule and estimate. Then build it, manage what changes, verify the result, and put somebody in the position of deciding whether it is fit for operation.
In my view, this is much closer to how lunar construction capability should be proven.
How I Would Run the Construction Rehearsal
I would run it as a project, not as a technology trial.
The first requirement is an owner. Someone defines what must be delivered, sets the performance requirements, and eventually accepts the finished asset. The owner should not prescribe the excavator, rover, or construction technology. The delivery team should solve that.
The scope should also be deliberately small. There is little value in trying to rehearse an entire lunar base. The first campaign needs a civil package that can actually be completed, measured, and accepted.
I would start with something like a prepared work area connected to a short mobility corridor and utility trench. It is simple enough to control, but it immediately forces several construction functions to work together: investigation, excavation, haulage, grading, survey, ground engineering, equipment movement, logistics and installation.
Then start with the site as a real project:
Provide terrain mapping, imagery, limited geophysics, selected penetration or sampling data, and a preliminary interpretation of the ground. Include uncertainty. Do not hand the construction team a perfectly characterized test pit.
The delivery team then has to decide whether the available information is sufficient to commit to a construction method or whether further investigation is required.
From that information, develop a construction ground model. It should define the ground units relevant to the work, expected excavation response, trafficability, likely obstructions, bearing conditions, material-handling behavior, and the confidence attached to those assumptions.
The important point is not that the model must be perfectly correct. It will not be. It must be explicit, traceable, and usable for construction decisions.
Before breaking ground, freeze a baseline. Define the construction method, equipment fleet, quantities, expected production, power demand, sequence, schedule, estimate, contingency, and verification requirements.
Now there is something meaningful to test.
If excavation takes twice as long as assumed, that matters. If power becomes the bottleneck, it matters. If the ground model changes, you can measure the effect on production, sequence, equipment, and cost rather than discuss it afterward as a lesson learned. Then operate the site as a jobsite.
Establish survey control. Define work zones and haul routes. Set up equipment staging, material stockpiles, temporary power and communications. Provide maintenance and recovery areas. Control access. Plan daily activities. Record production, downtime, power consumption, equipment utilization, material movement, and rework.
That operating approach is what turns a test field into a construction rehearsal. The main objective is no longer to prove that a machine can perform a task; instead, the focus is to determine whether the project can still deliver the asset when ground conditions, production, interfaces, and assumptions begin to move.
If the rehearsed asset is intended to support people, the site plan has to carry the human-support systems from the beginning. Water, waste, hygiene, consumables, storage, maintenance access and service corridors are not downstream operational details; they become inputs to the civil layout, construction sequence, temporary works and utility strategy. A construction rehearsal should expose those interfaces early, before they become conflicts in the permanent design.
Build uncertainty into the jobsite, and control it
Don't run a construction rehearsal on perfectly prepared, fully characterized ground. That is useful for technology testing, where repeatability matters. A jobsite is different.
NASA’s MMPACT program, autonomous excavation and site-preparation work, JAXA/Kajima’s remote construction trials, and ESA’s LUNA facility all show that the sector is steadily integrating excavation, mobility, autonomy, materials and surface operations.
The gap addressed here is different: operating those capabilities under a construction-delivery framework with ground uncertainty, project controls, verification, acceptance and handover.
The site should contain controlled uncertainty: zones of higher excavation resistance, buried blocks, disturbed material, weak or loose horizons, changing trafficability, and areas where production falls below the baseline. The construction team should know that variability exists, but not exactly where every condition will be encountered.
The purpose is not to catch the equipment out. It is to test whether the engineering and project-control system recognizes the change, understands its consequence, and responds correctly.
That response should be managed the same way it would be on a serious infrastructure project. The construction method is documented. Inspection and test plans define what is checked and by whom. Hold points prevent work from proceeding until critical conditions are verified. Nonconforming work is recorded and dispositioned. Changes to the ground model, construction method, schedule, production assumptions, or estimate are controlled and traceable.
Daily records should capture what actually happened: quantities, equipment hours, power use, downtime, delays, rework, material movement, and deviations from the baseline. The final record should show what was actually constructed, not simply what was intended.
NASA already has mature verification and validation processes. The additional construction layer is to apply that suggestion directly to the modified ground and the completed civil asset.
That is, what separates a technology demonstration from a construction rehearsal: uncertainty is allowed to enter the project, but it is not allowed to enter unmanaged.
Developers must consider that production is not the machine rate
A machine can excavate 10, 50, or 100 tonnes per hour, and the project can still deliver 30. There is nothing contradictory about that. One number describes equipment performance under a defined condition. The other describes what the construction system can actually sustain.
This is one of the basic rules in mining, tunneling, and heavy civil work. Production is rarely governed by the excavator alone. The ground, the cut, haulage, trafficability, queueing, power, equipment availability, maintenance, survey control, inspection, rehandling, rework, and the capacity of whatever sits downstream govern it.
For a lunar construction rehearsal, you have to measure those losses at the project level. Excavation output matters, but so do haul cycles, waiting time, slip, power consumption, wear, maintenance, material losses, equipment utilization, and interface delays. A high instantaneous production rate may still result in poor daily output if the rest of the system cannot absorb it.
That does not invalidate the machine. However, it exposes the project. Moreover, construction production should be considered a system property, and the ground model must also remain live during execution. It should not be treated as a document completed before construction and then left unchanged.
If excavation resistance increases, buried blocks appear, trafficability deteriorates, or a material behaves differently from the baseline, the team should record and interpret the condition. The team then decides whether the ground model needs revision, whether the construction method remains suitable, and what the change means for safety, asset performance, production, schedule and cost.
Sometimes the method changes. Sometimes only the production assumption changes. Sometimes additional investigation or verification is required before work continues. That is not a failed test, but it is how difficult ground is managed on real projects.
The value of the rehearsal is therefore not only the final production number. It is the record of why production changed, how quickly the project recognized it, what decision was made, and whether the asset could still be delivered within an acceptable construction envelope.
That is far more useful than proving a machine can achieve a headline rate under one prepared ground condition.
Finish the Job
Developers should not stop when the machine stops. An excavator completing the cut, a rover finishing its route, or a grading system reaching its target demonstrates that a technology can perform a task. Construction has a different endpoint. The work must be surveyed, verified against its requirements, documented as-built, and either accepted or rejected by someone responsible for the asset.
A serious construction rehearsal should therefore finish with the same evidence expected from infrastructure practice: final survey, ground verification, performance testing, construction deviations, nonconformance closure, equipment-performance records, residual risks, and a completion dossier. An accepting authority, independent of the equipment developer, then decides whether to accept the asset, accept it with defined limitations, or reject it. That decision is far more useful than declaring a demonstration successful. The machine is not the final product. The test article is the completed infrastructure.
Acceptance should also lead into operation. Put the finished asset to work. Run repeated traffic over the mobility corridor. Load the prepared ground. Operate equipment from the working surface. Use the utility installation and monitor settlement, rutting, degradation, maintenance demand, and performance loss. This is where design assumptions meet operating reality. It also starts generating the information needed for maintenance, defects management, operating limits, future expansion, and the next construction campaign.
None of this requires another expensive lunar test facility. Existing NASA terrain fields, LUNA, university testbeds, quarries, mines, heavy-equipment proving grounds, or suitable volcanic terrain could all host this type of campaign. The important change is not the simulant recipe or the location. It is how the site is operated. Give the exercise an owner, a defined civil asset, incomplete but credible site information, a construction ground model, a frozen production and project-control baseline, interacting work packages, temporary works, change procedures, QA/QC, independent verification, formal acceptance, and operational handover.
That is the maturity step I would put in front of developers now. Move beyond proving that equipment works under selected conditions. Demonstrate that several systems can deliver an infrastructure asset, manage deviations from plan, verify what was actually built, and hand it over for operation.
What This Program Is, and What It Is Not
A terrestrial construction rehearsal should not pretend to reproduce the Moon. It cannot directly validate lunar excavation rates, one-sixth-gravity trafficability, vacuum-dependent granular mechanics, electrostatic dust behavior, lunar thermal response, plume-surface interaction, or the true mechanical response of lunar regolith at construction scale. Those problems still belong to reduced-gravity testing, environmental chambers, numerical modeling, specialist facilities and, eventually, in-situ lunar demonstration.
The program's value is not physical imitation. It is construction delivery under realistic project constraints.
Existing programs are already advancing excavation, autonomous equipment, site preparation, materials, robotics and integrated surface systems. The opportunity is to put those capabilities inside a construction framework and see whether they can deliver one civil asset when ground assumptions, production, power, interfaces, and sequence begin to move.
That means the program should be run as infrastructure, not merely as a research consortium. The program needs an owner or sponsor, a designer, a ground engineering authority, a construction integrator, technology and equipment providers, an operations lead, and an independent verification and acceptance function. Universities and research organizations remain important partners, but someone has to own delivery.
In other words, the objective is no longer to demonstrate that several technologies can operate together. The objective is to deliver an asset against requirements, manage deviations from the baseline, verify what was actually built, and decide whether the residual risk is acceptable.
The first campaign would almost certainly expose weaknesses. That is exactly why it should happen on Earth.
Its real product is not only the pad, corridor, or foundation area. It is the construction record: which assumptions were wrong, where production was lost, which interfaces became bottlenecks, how much power was actually consumed, where rework occurred, what information about the ground proved useful, how verification affected the schedule, and what to change before the next campaign.
That is how first-of-a-kind infrastructure matures. Nuclear projects, tunnels, mines, and other major civil works rarely become repeatable because the first project went perfectly. They become repeatable because the first project generated disciplined evidence that the second project could use. That is how first-of-a-kind work becomes repeatable delivery.
This is also the boundary the article should protect. It would be wrong to say that NASA only tests machines, that nobody integrates lunar construction, or that structural construction is not being tested. Significant work already exists across NASA, Japan, ESA and industry.
The technical elements of lunar construction are increasingly being integrated. The next maturity step is to rehearse the behavior of the construction project itself by bringing ground uncertainty, means and methods, temporary works, production, project controls, changed conditions, QA/QC, acceptance, handover and risk ownership into one delivery exercise.
My view is straightforward: rehearse that construction project on Earth first. Use the testbeds and technologies that already exist but run them as a jobsite. Give the work an owner, a ground model, a baseline, construction controls, an accepting authority, and real consequences when assumptions move.
Let Earth absorb the first construction mistakes. The Moon is too expensive a place to learn them for the first time.
Roberto Moraes
Lunar Construction Strategist | Author | SpaceGeotech
Comments