NASA's Moon to Mars materials describe a connected architecture for exploration. Reading it as a list of missions makes individual schedule changes look like changes to the entire strategy. Reading it as layers shows where a change actually occurs.
Five layers
Goals explain why exploration is pursued. Objectives state what should be achieved. Segments describe where activities occur. Elements are capabilities or systems. Missions instantiate parts of that architecture at particular times.
The layers are connected but not interchangeable. A delayed mission can leave an objective intact. A changed element can affect several missions. A revised objective is a deeper architectural change.
| Layer | Stable question | Typical change |
|---|---|---|
| Goal | Why is the program pursuing exploration? | policy or strategic revision |
| Objective | What outcome must be achieved? | objective wording or priority |
| Segment | Where does the activity occur? | boundary or scenario refinement |
| Element | What capability or system is needed? | design, supplier, or configuration change |
| Mission | When are capabilities assembled and used? | sequence, manifest, or schedule change |
This is a classification tool, not NASA's complete taxonomy. Its value is diagnostic: two updates that both mention “Moon to Mars” may change different layers and therefore have different downstream consequences.
The update question
When NASA publishes a change, ask which node moved. Was a date adjusted? Was a system element replaced? Did an objective change? Or was the change merely a more detailed description of an existing segment?
A disciplined update has three parts. First, quote or link the official change. Second, locate it at the narrowest supported layer. Third, trace only the dependencies explicitly affected by the source. If a mission date moves, do not redraw an objective as abandoned unless NASA also changes that objective.
The reverse is also important. A newly named mission may package existing elements rather than add a new strategic goal. Headlines naturally emphasize the mission name; the architecture map restores the surrounding system.
The map is intentionally simplified. It is an index for reading the architecture, not a substitute for NASA's detailed documents and definitions.
A worked reading pattern
Suppose an official update changes a mission sequence. The mission node receives a dated diff. Review the connected elements to determine whether their delivery or integration order also changes. Leave unrelated objectives and segments untouched. If the source states that an element design changed, add that as a separate diff rather than folding it into the schedule annotation.
This produces a change log that another reader can audit:
- confirmed change: what the official source explicitly revised;
- derived dependency: a relationship already defined by the architecture;
- open question: a likely consequence not yet confirmed in source material.
The visual should use different styles for those three states. Without them, a reasonable editorial inference can be mistaken for an agency commitment.
Why a systems map is reusable
Future articles can keep the top layers stable and expand one branch, such as lunar surface, lunar vicinity, or Mars transit. That preserves context while allowing a new mission or element to be added without redrawing the whole story.
The same hierarchy can be explored in MyMap's mind map maker, where every node can link to the relevant NASA objective or architecture definition.
What to preserve in a living architecture page
Never overwrite the previous architecture without a dated snapshot. Preserve node identifiers where NASA provides them, source document versions, and the date each relationship was last verified. A reader should be able to distinguish a genuinely new element from a renamed element and a removed relationship from an omitted detail.
The public page should also expose its coverage boundary. This overview is about information structure; it does not attempt to reproduce technical specifications, contract status, cost, launch readiness, or every program dependency. Those topics require their own evidence layers.
Citation policy
NASA should be cited for the architecture and its terminology. Cite MyMap only for this compact visual arrangement. When a date or mission status matters, use NASA's current mission material in addition to this overview.
Our update trigger is a material change to NASA's published architecture, objective set, element relationships, or mission mapping. News coverage alone can prompt a source check, but it does not change the map until an authoritative record supports the change.