Skip to content

Wiki rules: Moon to Mars architecture

This wiki compiles NASA's Moon to Mars architecture into linked markdown pages, following Karpathy's "LLM wiki" pattern: raw sources stay untouched, the wiki is written and maintained by the model, and this file sets the rules. The project lead decides what changes in these rules.

Scope

  • The architecture only. Sources are the files under sources/text/ and sources/moon-base/ and sources/linked/ (and the raw PDFs in sources/raw/docs/ when a table or figure needs checking), plus the slide images in sources/raw/slides/. Nothing from other datasets or projects, such as program portfolios or technology databases. Work that builds on the architecture belongs outside this wiki.
  • Nothing from memory or the web. Every claim must come from a source file and carry a citation. Background you'd like to add but can't cite goes to open-questions.md, not into a page.
  • Readers are NASA colleagues and others new to these documents. Plain English, dense, specific. Quote NASA's own wording for key definitions.

Layout

Path What goes there
index.md Catalog of every page: link, one-line summary. Updated every session.
log.md One entry per session, newest first: ## Session N — YYYY-MM-DD — <queue item>
queue.md Ordered work list. Each session takes the first unchecked item.
open-questions.md Questions for the project lead, contradictions between sources, decisions not covered here
overview.md Top-level synthesis (written near the end of the queue)
sources/<file-name>.md One page per source document (name = its text file name)
sources/index.md All sources with provenance. Generated by tools/wiki/sources_page.py; don't edit by hand
moon-base/ Moon Base: phases, priorities, needs, missions and assets
gaps/esdmd-NNNN.md One page per architecture technology gap (e.g. esdmd-0801.md)
data-gaps/<id>.md One page per architecture data gap (e.g. dn-001-l.md)
segments/, sub-architectures/, elements/ The architecture's building blocks
objectives/ Moon to Mars objectives and their decomposition
concepts/ Use cases, functions, recurring tenets, other cross-cutting ideas
glossary.md Acronyms and terms

Create folders as needed. Prefer updating an existing page over creating a near duplicate.

Page format

Start every page with YAML frontmatter:

---
title: Lunar Dust-Tolerant Systems and Dust Mitigation
type: gap            # source | gap | data-gap | element | segment | sub-architecture | objective | concept | moon-base | overview
sources: [2025-12-2025-architecture-driven-technology-gaps, 2025-12-add-revision-c-20251211]
updated: session 3, 2026-10-01
---

Then a two-to-four-sentence summary, then sections. Gap pages use these sections: Summary, Description, Current state of the art, Performance target, Child gaps, Traceability (use cases, functions, definition tasks), Segments and sub-architectures, Priority (bin and rating, with what the rating means if a source explains it), Moon Base relevance, Related pages, Sources.

Lists: leave a blank line before every list, and indent nested lists by 4 spaces per level. The published site renders with MkDocs, which needs both (adopted 2026-10-01).

Write content pages as finished pages for readers: no "Session N additions" blocks and no session-number phrasing ("session 12 found", "(session 33)"). Put new material in the section it belongs to, and state what the source says with its citation. The history goes in log.md and the page's updated: line (adopted 2026-10-01).

Citations

  • Cite inline as a link to the source page plus page number: ([ADD Rev C, p. 77](../sources/2025-12-add-revision-c-20251211.md)). For spreadsheets cite the sheet and row ID instead of a page. For web pages (no page numbers) cite the section heading in quotation marks: ([Moon Base Phases, "Phase One"](../sources/nasa-gov-moonbase-phases.md)), and give the page's own date on its source page, or the fetch time if it has none. (Adopted from session 1, 2026-10-01.)
  • Graphics-heavy pages lose content in text extraction. When a page's text looks scrambled or thin, check the raw PDF page before relying on it.
  • Quote exact wording in quotation marks when the wording matters.
  • If two sources disagree, say so on the page, cite both, prefer the newer one, and add the contradiction to open-questions.md.

Versions and dates

  • Every source page states the document's date and version.
  • The current architecture is ADD Rev C (Dec 2025), its two gap spreadsheets (Dec 2025), the 2025 Architecture Update and the Moon Base Users Guide (Apr 2026). Older documents (2022–2024) are context: where they differ, say what changed.
  • Moon Base was announced in March 2026, after ADD Rev C. Don't assume ADD segments map to Moon Base phases; record a mapping only where a source makes it.

Workshop slides (added 2026-10-01)

The slides and posters from NASA's architecture workshops (February 2024, February 2025 for two audiences, January and February 2026) are tier 3 sources. sources/workshops-screening.md lists every deck with its text-poor slides, near-copies and overlap with documents already read. Use it to plan each session.

  • Rank. Slides are briefings, not the architecture of record. ADD Rev C and its companion documents, the 2025 Architecture Update and the Moon Base Users Guide stay the reference. Where a slide says something newer or different (the 2026 workshops came after Rev C), record it next to the Rev C statement, for example "briefed at the January 2026 workshop", cite both, and add a real conflict to open-questions.md. Don't replace the Rev C statement.
  • One source page per deck (name = its text file name). Cite slides by number, which is the PDF page: ([2026 industry and academia workshop, slide 12](../sources/2026-01-industry-and-academia-for-export-control-v3.md)).
  • Read text-poor slides from the image, sources/raw/slides/<deck>/slide-NN.jpg. Check the image of any other slide when its text looks scrambled or a chart carries the point. Posters have poster-tile-1.jpg to -4.jpg for small print.
  • Near-copies. Read the primary deck in full. The copy gets a short source page saying what differs; compare the text and look only at the images of slides that differ.
  • Briefings of papers the wiki has already read: record only what the slides add.
  • Partner posters (2026, Rome) are the partner agencies' own material, hosted by NASA with their permission. Attribute them to the agency ("ESA's poster says …"), never to NASA's architecture.
  • sources/index.md is regenerated by a script after the run; don't edit it.

Moon Base lens

Gap, data-gap and element pages get a "Moon Base relevance" section: which Moon Base phase or priority it serves, with a citation. If no source says, write "Not established by the sources so far."

The Users Guide labels only its functional gaps "Phase 01". Its 19 technology gaps and 19 data gaps are "near-term Moon Base development" challenges, which Phase 1 missions help close "to enable essential phase two and phase three capabilities" (pp. 8–13). Label them "named in the Moon Base Users Guide (near-term)", never "for Phase 1" (decided 2026-10-01, question 73).

Conventions adopted from open questions (2026-10-01)

The project lead adopted the wiki's working practice on these questions as rules.

Page sections (after the opening summary)

  • Data-gap pages: Description (plus "Data utility" where the white paper's Table Two gives one), Need driver and data type, Target measurement parameters, Current state of data, Impact if data is unavailable, Benefits if data is available, Traceability (objectives and segment), Priority (always "None", with the source's reason), Moon Base relevance, Related pages, Sources. (q. 18)
  • Segment pages: Description, Objectives, Reference missions, Elements, Areas of future work, Gaps that list this segment, Changes since Rev C, Moon Base relevance (no source maps segments to phases), Related pages, Sources, plus segment-specific sections. (q. 23)
  • Sub-architecture pages: NASA's description (in full), In the segments, Elements, Technology gaps, a section per other source on the subject, Moon Base Phase 1 (the Users Guide's grouping of Phase 1 functional gaps, p. 9), Related pages, Sources. (q. 23)
  • Element pages: NASA's description (in full), At a glance (the one-pager's facts and header-image caption), element-specific sections, Functions (ADD Appendix B.3) with a "Moon Base Phase 1 functional gap?" column, Gaps that mention it (gaps whose text names the element), Changes since Rev C, Moon Base relevance, Related pages, Sources. (q. 24)
  • Tenets: the hub concepts/recurring-tenets.md holds their wording. Each tenet's page, concepts/rt-N-<slug>.md, has The assessment, Future considerations, Changes since Rev C, Related pages, Sources. (q. 26)
  • Appendix B list pages (lunar and Mars use cases and functions): How this page is built, At a glance, a section per sub-architecture letter, comparison notes, Related pages, Sources. The hub Use cases and functions explains B.1 and the IDs. Appendix A is split between Why Moon to Mars and Objectives. Mars list pages add a decomposition column; lunar ones point to the objective pages instead, and keep doing so. (q. 41, 44, 63)
  • Objective and C&N pages (type: objective): one page per body, not per objective, tabulated by goal or by letter, with At a glance counts and a section on unlinked items (e.g. C&Ns with no use case). Lunar function allocation holds the allocation comparisons. (q. 44, 63, 68)
  • Glossary (type: concept): transcribe only ADD Appendix F (F.1 acronyms, F.2 terms in printed order, F.3 descriptors). Then compare other sources' definitions and list what F leaves out. (q. 57)
  • Concept pages (tenets, lists, glossary) have no Moon Base relevance section. (q. 26, 34, 41, 57)

One home per topic

  • Source pages hold contents, what the PDF shows that the text loses, what changed by Rev C, and oddities (slips recorded as printed, not corrected). A source's content goes in one section on its subject's topic page; other pages link there. (q. 34, 47, 52, 55, 59, 67, 70)
  • Older sources (2022–2024) get a section headed with source and year, e.g. "In the executive overviews (2023 and 2024)", ending with a "What changed by Rev C" list labeled as the wiki's comparison. On element pages they get one only for something element-specific. Their figures keep their year. (q. 47, 55, 67)
  • Newer sources go under "Changes since Rev C", which is present only where one bears on the page. Quote them without inference; silence is an omission, not a change. (q. 24, 26)
  • On gap pages, a paper on the gap's subject gets one "Related pages" bullet labeled "the pairing is the wiki's" (one exception: #0101's "In the 2024 executive overview"). Sources that predate or don't mention the Moon Base leave Moon Base relevance unchanged. (q. 34, 47, 55, 67, 68)
  • A topic with no home gets a new concept page. An appendix a level below its topic gets its own page. Papers on one segment may get a hub section on its page. (q. 34, 52, 67)
  • Content with no architecture bearing stays on the source page, as do a web page's differences from a source it repeats. The glossary links to the objectives page's definitions. (q. 52, 57, 70)

Links and columns the wiki derives

  • Label every join the sources don't make where it appears ("the wiki's join", "the pairing is the wiki's", "the wiki's link"). Keep joins apart from source-made links, which come first in Moon Base relevance. Joins in use: gap and element functions against the Phase 1 list; same-subject Users Guide passages; Phase 1 missions against data gaps; Moon Base assets and sheet assets matched to elements by name or wording; tenets paired with gaps; "All FN" expanded (gaps index only). (q. 11, 24)
  • A column where each source names the ID itself (gaps citing an ID, the Users Guide's Phase 1 group) is source-made, not a join. (q. 11, 41)
  • Derived columns and counts are read off printed fields and labeled as derived, saying how: the gaps index's Destination and ID-group sub-architectures; counts by segment and sub-architecture. (q. 16, 23)
  • Data-gap pages print objective codes unlinked; the data gaps index's reverse table links them. (q. 19)

Citing

  • Cite a one-sheet workbook by row ID ("Tech gaps spreadsheet, ESDMD #0801"), a multi-sheet workbook by sheet name and row ID, and a non-data sheet, such as a Key sheet, by its name. (q. 12)
  • Where printed and PDF page numbers differ, cite PDF pages (the [page N] markers), write "PDF p.", and give both numbers on the source page. The 2025 Architecture Update's citations from session 9 say "p." for PDF numbers; leave them. (q. 29)
  • For an undated web page, image upload paths may serve as indirect evidence of date. (q. 70)

Wording

  • Quote the Moon Base Users Guide pp. 12–13 in the form a reader sees on the rendered page ("dust tolerant", "in depth", "large scale", "crew rated", "survive the night"), not the text layer's hyphens. (q. 17)
  • Where two December 2025 sources differ, show both on the page; derived counts follow the spreadsheet. (q. 38)
  • The 2022 wording of the objectives, goals and tenets is treated as current, because the newest documents print it; 2023 variants are listed on the objectives page. (q. 50)

Naming and scope

  • Keep the existing source-page names, including the long truncated ones (renaming breaks links). (q. 2, 70)
  • Use H2M for Humans to Mars. (q. 23)
  • A NASA article reporting a talk is cited "as reported", with the speaker named; it ranks below the documents. (q. 74)
  • A deck keeps the date its listing page gives; a probable earlier delivery date goes on its source page as the wiki's reading. (q. 83)
  • A 2023 white paper filed as a workshop briefing is treated as a 2023 paper and cited by page. (q. 92)

Matching other lists to the gaps

  • Don't match lists that don't name architecture gaps (partner posters' capabilities, STMD's civil space shortfalls) to the technology gaps by title. Keep them on their source pages. (q. 85, 87)
  • Where a source presents its items as ADD technology gaps without IDs (the Mars Campaign Office's priority areas), a title match on the gaps index is allowed, labelled as the wiki's. (q. 88)
  • A gap page may carry an earlier version of that same gap's table when a source prints it (#0101, #0301), in a section named for the source. (q. 89)
  • Keep the single quotation of ADD Rev C's own note pointing to TechPort (p. 200) on the gaps index; use no TechPort data anywhere. (q. 36)

Each session

  1. Read this file, index.md, the newest three entries in log.md, and queue.md.
  2. Take the first unchecked item in queue.md. Read its source files.
  3. Write or update pages. Link generously between pages.
  4. Tick the item in queue.md and note the session number next to it. If you couldn't finish, tick what you did and insert a new item right below for the rest.
  5. Update index.md. Prepend a log entry: what you read, pages created and updated, anything surprising, what the next session should know.
  6. Stop. Don't start a second queue item. The runner commits your work.

When something isn't covered by these rules, don't decide it: write it to open-questions.md and carry on with the queue.