From Principle to Practice: How Designated Lunar Areas Actually Work
AUTHOR: AARON MACKEY
As the first wave of lunar mining, landing, and power operations converge on the Moon's south pole, there's no rulebook for who gets to operate where. Open Lunar's Designated Lunar Areas framework offers a way for operators to declare their footprint, share the data behind it, and coordinate with their neighbors before conflicts become crises. Here's how the three-ring structure works, and why the window to adopt it is open right now.
A lunar mining company is finalizing plans for its first extraction operation. The site is in Shackleton crater. The mission planner opens the Open Lunar proposed decision-support framework for surface coordination and begins entering parameters: expected dust production of roughly 100kg over a four-hour window, assuming no mitigation measures in place. This isn’t the company’s first time operating in this area of the crater, so they feel confident in their assumptions. They dial the confidence value to +/- 10%.
The toolkit flags: Moderate Hazard – Coordination Zone Required.
The flag isn’t a surprise. This operation was expected as a moderate hazard ever since the company completed its low-hazard site surveys, and the mission planner knows the flag reflects the best available scientific inputs about the likely dust footprint. It is known best practice that before moving forward, the company needs to register a Designated Lunar Area. So what does that actually mean, and what happens next?
The Three-Layer Structure of a DLA
Open Lunar’s Designated Lunar Areas (DLAs) are a proposed coordination framework, a concept developed by Open Lunar to fill a governance gap that existing space law does not address. A DLA is not a territorial claim and not a regulatory instrument. It is a structured way for lunar operators to declare their operational footprint, share the data behind it, and coordinate with neighbors before conflicts arise. A DLA consists of three concentric rings, each with its own rules, its own obligations, and its own logic. Understanding the difference between those three rings (the concentric zones that make up a DLA) is the difference between understanding DLAs as a concept and knowing how to actually use one in practice.
(The Three-Layer Structure of a DLA from the Lunar Field Guide)
The Core Operations Zone - Orange
The Core Operations Zone is the innermost ring and the active footprint of your mission. It is the zone where you have the strongest justification for an operational radius, and where interference from a neighboring actor would most directly threaten your mission (and their own).
Operators should meet a high bar for claiming exclusive access to a surface area. A weak or poorly justified exclusivity claim is not just unfair to neighbors; it is the kind of precedent that leads to runaway land grabs. The Core Operations Zone is designed to avoid that. Exclusivity here is not assumed; it is earned through proactive and transparent communication about what is actually happening inside the zone. It is important to note that exclusivity here isn’t appropriation but rather an operational necessity based on empirical evidence and thoughtful estimation. For exclusivity in a Core Operations Zone to carry any real weight, the operator needs to publish the planned activity and expected duration, a running log of actual operations as they occur, and a ‘post-mission log’ of deviations from the original plan after operations cease. Transparency is not supplementary to the Core Zone; it is what makes the claim to operational exclusivity legitimate.
The Harmonization Zone - Teal
Moving outward from the core, you enter the Harmonization Zone. This ring must be appropriately sized for the actual hazard profile of your operations because this is where operations stop being solely under your control, and limited activity by your neighbors is permissible within this area as well.
As operations proceed in the Core Ops Zone, other operators may move their assets through the Harmonization Zone with advance coordination and under specific protocols. Operators should publish the model behind their declared hazard boundary (whether that is a dust dispersion simulation, a thermal plume estimate, or a comms interference radius) so that neighbors can evaluate whether the buffer is appropriately sized. As operations proceed, actual outcomes get logged and compared to those published models. Discrepancies between predicted and actual hazard zones trigger a review and an update.
The Coordination Area - Grey
The outermost ring is the Coordination Area, the zone where neighboring actors have a say, not a veto, and where structured dialogue takes the place of unilateral action. Operators whose Coordination Areas overlap are expected to be in communication, not just to broadcast their intentions, but to actually engage. What does that communication look like in practice? At minimum: an open line of communication between stakeholders on planned entry and exit corridors, rover paths, activity schedules with high-hazard windows flagged, any changes to the DLA since initial registration, and contact information and response protocols.
Taken together, the three rings establish a clear hierarchy of obligation:
Core Zone: transparency obligation: publish your activity, log your actuals, document your deviations.
Harmonization Zone: shared responsibility: size your buffer honestly, share the model behind it.
Coordination Area: communication obligation: notify neighbors, engage in dialogue, stay reachable.
Each ring has different rules because each ring represents a different relationship between your operations and the actors around you during the set period of operations.
A Quick Note on Landers
Landing deserves its own treatment within this framework. It is a distinct hazard category (the single highest-acute-impact event in a mission’s lifecycle) and warrants its own decision logic path rather than being folded into general surface operations. The key inputs for a landing hazard estimate are total lander mass and the downward thrust profile in the final ten to twenty meters of descent. A hover-slam approach produces significantly more dust than a final RCS-jet descent. As only a handful of operators have ever landed on the Moon, most are working with very limited real data. The framework needs to expect and accommodate large confidence margins rather than treat low-confidence estimates as precise. Post-mission retrospectives feed the system, improve future confidence values, and give operators who come after something real to calibrate against. Until that data accumulates, landings should be given extremely wide margins both in location and in error.
The Ground Rules Decision Logic
The Ground Rules Toolkit is a decision-support framework that builds an operational layer on top of the three-ring DLA structure. Where the DLA defines the geography of coordination (the zones, the boundaries, the obligations), the Toolkit translates that geography into a set of decision rules that mission planners can apply before and during operations. The three-ring structure tells you what a DLA is. The Ground Rules Toolkit tells you what to do with one.
Before the Toolkit can function, operators need to have done something first: a pre-mission survey of the area, a check of activities already registered in the Lunar Ledger, and Open Lunar’s proposed shared registry of lunar surface operations. Who else is operating in your area? What are their hazard profiles? Where do your zones overlap? Establishing this survey as a norm (a standard step in mission planning, not an optional courtesy) is as important as the logic chains themselves. Coordinating with nearby operators and sharing data on a shared Ledger is what makes the survey meaningful.
Once the survey is complete, the logic chains take over:
If two Core Operations Zones overlap → mandatory deconfliction before either mission can proceed
If Buffer Zones overlap but Cores don’t → coordination required; negotiated adjustment recommended
If only Coordination Areas overlap → notification required
If a rover path crosses another operator’s Harmonization Zone → flagged for review; rerouting preferred
If a landing is planned → separate path: lander mass plus thrust profile plus landing ellipse uncertainty produces an estimated dust hazard radius, checked against neighboring DLAs with low confidence assumed
If an asset is reaching end-of-life → controlled disposal zone designation required; checked against active surface operations in the target area
(Overlapping DLA scenarios in a shared crater)
A Core overlap triggers mandatory deconfliction because two active footprints in the same space are an immediate operational conflict. A Coordination overlap only requires notification because the risk is lower and the relationship is about dialogue in operations, not exclusive access of a site. This is a coordination infrastructure in practice. Rather than building a lunar court, a regulatory body, or an enforcement mechanism, the goal is to incentivize operators to resolve conflicts before they become crises, and to build the kind of structured self-coordination that makes future conflict less likely.
One might roll one’s eyes at the efficacy of non-binding coordination structures, but Elinor Ostrom’s research on governing the commons is instructive here. Her work showed that decentralized, polycentric governance (where actors take a direct stake in managing shared resources) consistently outperforms top-down regulation on both stewardship quality and outcomes for the actors themselves. The DLA system and supporting Ground Rules Toolkit are built on this principle. Operators who participate in the Lunar Ledger, run tabletop simulations, share data, and coordinate through the Toolkit aren’t just following top-down rules. They are co-stewarding a shared resource with a shared incentive for successful outcomes.
Yet there is still a useful tension worth naming: what happens when an operator refuses to share data? They still have to declare some area of operations if only for their own lunar assets. And the incentive structure for operators who won’t share real data would likely default to declaring maximum buffers without any time-bound constraints. This wastes coordination space and signals bad faith to not only other operators but also customers who want verifiable, responsible operations. Think of it like automotive safety ratings. The Toolkit gives operators a way to demonstrate responsible operations in a form that customers, insurers, and agency partners can actually evaluate. Operators who publish verifiable metrics attract business. They’re tested and validated by virtue of their engaging in transparency. Competitors will want the same credentials, or better, and would in turn have an incentive to opt in to the DLA framework.
Test Simulation: Three Operators at the South Pole
The framework is easier to understand in motion. Here’s what it looks like when three operators, each with different mission profiles and each acting in good faith, converge on the same region.
(Test Scenario Illustration)
Operator A is preparing a large lander for touchdown near the south pole, engines firing all the way to touchdown rather than switching to attitude control jets in the final meters. That approach comes with a known tradeoff: significantly elevated dust production during the landing event itself. Additionally, the landing ellipse isn’t a fixed point, backup landing sites have been identified, and hazard avoidance algorithms could shift touchdown laterally, while an abort-and-retry scenario could move it further still. Operator A registers their DLA on the Ledger with a landing hazard estimate that accounts for ellipse uncertainty, flags their thrust profile, and publishes their dust dispersion simulation with a wide confidence margin that reflects how little real data exists.
Operator B is managing a beamed power network in the same region: a constellation of assets delivering laser energy across the surface to receivers. Their infrastructure is sensitive in two directions: dust lofted by nearby operations can attenuate the laser beam and degrade power delivery, and the beam itself, while not structurally dangerous, can temporarily blind IR cameras on neighboring assets if the targeting handshake fails. Operator B has registered their network geometry on the Ledger, including the retroreflector-based targeting protocol that auto-shuts the beam if receiver lock is lost.
Operator C is running lunar extraction operations with a core zone that depends on undisturbed regolith. Their process doesn’t tolerate surface disruption: a contaminated or disturbed extraction site means a compromised mission. They’ve been operating in the area the longest and have the most ground truth on local regolith behavior. Their DLA is fully registered, their dust models calibrated from prior operations, and their confidence margins are tight.
Before Operator A’s mission planning is finalized, they run a pre-mission survey of the Ledger. Both Operator B and Operator C are already registered. The survey returns two flags immediately.
The first: Operator A’s landing ellipse, accounting for dust projection and trajectory uncertainty, overlaps with Operator B’s receiver network. The Toolkit fires:
Buffer Zone Overlap Coordination Required.
Operator B’s beam geometry puts several receivers inside Operator A’s projected dust hazard radius. Dust attenuation during or after landing could degrade power delivery across the network. The two operators negotiate: Operator A refines their ellipse estimate and commits to a landing window timed to minimize overlap with Operator B’s peak delivery hours. Operator B documents the coordination in their Ledger entry and adjusts receiver sensitivity thresholds for the landing window.
The second flag: Operator A’s landing dust projection extends toward the edge of Operator C’s extraction zone. The Toolkit fires again:
Coordination Area Overlap Notification Required.
This isn’t a mandatory deconfliction; the cores don’t overlap, and the buffer intersection is partial, but Operator C needs to know. The notification goes out. Operator C reviews Operator A’s dust model against their own regolith data. They have more local ground truth than Operator A and identify that the actual erodibility of the surface in that area is higher than Operator A’s simulation assumed. They share that data. Operator A updates their dispersion model. The confidence margin is tightened. The landing hazard estimate on the Ledger is revised before touchdown. Operator A further adjusts their power operations while Operator C prioritizes the extraction of impacted areas before landing.
After Operator A lands, they log their actuals: touchdown coordinates versus planned, observed dust production versus the model, and any deviations from the registered descent profile. The retrospective lives on the Ledger. Operator C’s shared regolith data and Operator A’s post-landing ground truth means the next operator planning a similar landing in this region has something real to calibrate against, not just a simulation built on assumptions.
These three operators have three different mission profiles and three overlapping but distinct sets of interests. The DLA framework didn’t create the willingness to coordinate in these operators but what it allowed was a shared language, a shared record, and a shared decision logic that surfaced the conflicts early enough to resolve them before conflict arose.
Operator A is preparing a large lander for touchdown near the south pole, engines firing all the way to touchdown rather than switching to attitude control jets in the final meters. That approach comes with a known tradeoff: significantly elevated dust production during the landing event itself. Additionally, the landing ellipse isn’t a fixed point, backup landing sites have been identified, and hazard avoidance algorithms could shift touchdown laterally, while an abort-and-retry scenario could move it further still. Operator A registers their DLA on the Ledger with a landing hazard estimate that accounts for ellipse uncertainty, flags their thrust profile, and publishes their dust dispersion simulation with a wide confidence margin that reflects how little real data exists.
Operator B is managing a beamed power network in the same region: a constellation of assets delivering laser energy across the surface to receivers. Their infrastructure is sensitive in two directions: dust lofted by nearby operations can attenuate the laser beam and degrade power delivery, and the beam itself, while not structurally dangerous, can temporarily blind IR cameras on neighboring assets if the targeting handshake fails. Operator B has registered their network geometry on the Ledger, including the retroreflector-based targeting protocol that auto-shuts the beam if receiver lock is lost.
Operator C is running lunar extraction operations with a core zone that depends on undisturbed regolith. Their process doesn’t tolerate surface disruption: a contaminated or disturbed extraction site means a compromised mission. They’ve been operating in the area the longest and have the most ground truth on local regolith behavior. Their DLA is fully registered, their dust models calibrated from prior operations, and their confidence margins are tight.
Before Operator A’s mission planning is finalized, they run a pre-mission survey of the Ledger. Both Operator B and Operator C are already registered. The survey returns two flags immediately.
The first: Operator A’s landing ellipse, accounting for dust projection and trajectory uncertainty, overlaps with Operator B’s receiver network. The Toolkit fires:
Buffer Zone Overlap Coordination Required.
Operator B’s beam geometry puts several receivers inside Operator A’s projected dust hazard radius. Dust attenuation during or after landing could degrade power delivery across the network. The two operators negotiate: Operator A refines their ellipse estimate and commits to a landing window timed to minimize overlap with Operator B’s peak delivery hours. Operator B documents the coordination in their Ledger entry and adjusts receiver sensitivity thresholds for the landing window.
The second flag: Operator A’s landing dust projection extends toward the edge of Operator C’s extraction zone. The Toolkit fires again:
Coordination Area Overlap Notification Required.
This isn’t a mandatory deconfliction; the cores don’t overlap, and the buffer intersection is partial, but Operator C needs to know. The notification goes out. Operator C reviews Operator A’s dust model against their own regolith data. They have more local ground truth than Operator A and identify that the actual erodibility of the surface in that area is higher than Operator A’s simulation assumed. They share that data. Operator A updates their dispersion model. The confidence margin is tightened. The landing hazard estimate on the Ledger is revised before touchdown. Operator A further adjusts their power operations while Operator C prioritizes the extraction of impacted areas before landing.
After Operator A lands, they log their actuals: touchdown coordinates versus planned, observed dust production versus the model, and any deviations from the registered descent profile. The retrospective lives on the Ledger. Operator C’s shared regolith data and Operator A’s post-landing ground truth means the next operator planning a similar landing in this region has something real to calibrate against, not just a simulation built on assumptions.
These three operators have three different mission profiles and three overlapping but distinct sets of interests. The DLA framework didn’t create the willingness to coordinate in these operators but what it allowed was a shared language, a shared record, and a shared decision logic that surfaced the conflicts early enough to resolve them before conflict arose.
What's Still Unresolved
The DLA framework described here is designed as a coordination tool, but not a complete governance system. It doesn’t seek to answer what happens when operators aren’t cooperative, who validates or disputes a registration, or how the system holds when twenty operators are competing for access to the same crater instead of two. These questions don’t have clean answers yet, partly because the governance conversation is still catching up to the operational reality.
These tools need to be used, and these frameworks need to be tested with real stakeholder feedback before we get to the Moon. The proposed sandbox simulation for DLA governance, developed by my co-fellow Lauren Paulson, is the logical next step in that process, creating regimes that put operators in the position of making real asset deployment and resource extraction decisions under different configurations, and testing these tradeoffs in a visible and repeatable fashion before they harden into precedent.
The window for building this infrastructure is open now. The Moon is not yet congested. The actors who will shape the first decade of serious surface operations are still in planning phases, still reachable, still in a position to adopt coordination norms before the pressure of live operations makes coordination feel like a constraint rather than an asset. The work that happens in the next few years will set the precedents that shape lunar operations for decades.
The DLA framework described here is designed as a coordination tool, but not a complete governance system. It doesn’t seek to answer what happens when operators aren’t cooperative, who validates or disputes a registration, or how the system holds when twenty operators are competing for access to the same crater instead of two. These questions don’t have clean answers yet, partly because the governance conversation is still catching up to the operational reality.
These tools need to be used, and these frameworks need to be tested with real stakeholder feedback before we get to the Moon. The proposed sandbox simulation for DLA governance, developed by my co-fellow Lauren Paulson, is the logical next step in that process, creating regimes that put operators in the position of making real asset deployment and resource extraction decisions under different configurations, and testing these tradeoffs in a visible and repeatable fashion before they harden into precedent.
The window for building this infrastructure is open now. The Moon is not yet congested. The actors who will shape the first decade of serious surface operations are still in planning phases, still reachable, still in a position to adopt coordination norms before the pressure of live operations makes coordination feel like a constraint rather than an asset. The work that happens in the next few years will set the precedents that shape lunar operations for decades.
Aaron Mackey is a 2026 Open Lunar Fellow working on geospatial data applications professional leveraging remote sensing solutions to advance open-access frameworks for designated lunar areas and peaceful lunar development.
