# Tier 1 space systems — complete first expedition ## T1-OV01 — Status, authority and the Explorer This chapter is an additive design expansion for review. The supplied artwork is confirmed visual direction. The operational detail below connects that artwork to SUBSTELLAR’s approved world, equipment, production, settlement and recovery rules. Recipe quantities, processing rates, final model scale and capacity values remain tuning decisions. They should be visible decisions in the plan, not numbers accidentally inherited from an illustrative recipe grid. The current Tier 1 vehicle is the **Explorer Rocket**. It carries the player from Earth through the first orbital experiences to a lunar landing and a dependable return. “Tier 1 Rocket” is its compact item label. The supplied imagery repeatedly presents one recognizable white-and-orange vehicle and explicitly promises the Moon and back. The first campaign therefore uses one prepared Explorer rather than requiring players to manufacture separate orbital and lunar hulls simply because the earlier document described those capability categories separately. References: REF01, REF02, REF11, REF14 and REF15. The original Keel and Pilgrim passages remain available in the preserved document as earlier proposed hull directions. Their useful functions—an understandable launch body, a real cabin, accessible equipment, an independent lunar refuge—inform this plan. Their names and silhouettes are not additional mandatory Tier 1 craft. Atmospheric, Orbital, Lunar, Interplanetary, Deep-Space and Interstellar remain useful capability classes. A physical vehicle can support more than one adjacent class. The Explorer bridges the first orbital and lunar capability without promising Mars access. The user’s later-tier images remain visible as supplied concepts: REF06 is labelled Concept 2 / Earth Launch Site; REF07 is Concept 3 / Deep-Space Rocket. Their detailed systems, destination mapping and additional artwork belong to later slices. Their larger forms do not force Tier 1 into an advanced propulsion or heavy-industry gate. Tier 1 is accessible Earth engineering. Familiar iron, copper, glass, stone, redstone, useful fibers, seals and Earth-made ceramics are enough to build its first complete support chain. No Core journey, Heartglass, titanium-grade frontier plant, lunar material or rare creature drop is required to breathe, launch, land or return. Players still need a functioning workshop and a deliberate expedition plan. “Early” describes obtainable resources and understandable machinery, not a promise that the first rocket appears before the player has learned to build a home. ## T1-OV02 — What completing Tier 1 means Tier 1 completion is an operational accomplishment: the player has built and commissioned the equipment, made a lunar foothold, explored below the surface, brought home useful samples and made the next trip easier. A rocket sitting on a pad is a visible midpoint. Its surrounding industry and the life it enables on the Moon are part of the same product feature. | Stage | Player accomplishment | Useful equipment or project | Evidence of readiness | | --- | --- | --- | --- | | Earth workshop | Produce structural stock, seals, ceramics, basic circuits and field power | Existing TEC02, TEC03, TEC04 and TEC07 work | Recipes and services are available from reachable Earth inputs. | | Parts production | Turn those materials into identified rocket and suit components | T1-M01 Part Fabrication Table; TEC12 life-support workshop | Component purpose and missing supplies are visible. | | Supply preparation | Manufacture standard propellant, fill breathing containers and charge cells | T1-M03 Fuel Refinery; T1-M05 Oxygen Generator; existing charging service | A complete mission allocation can be prepared without lunar inputs. | | Vehicle assembly | Assemble and inspect a recognized Explorer | T1-M02 Rocket Assembly Station | Finished vehicle, cabin, cargo and system connections pass commissioning. | | Launch-site commissioning | Connect services and register Earth as a return destination | T1-M06 Launch Pad; T1-M07 Control Console; T1-M04 Fuel Pipe | Boarding, clearance, route, reserves and recovery are all legible. | | First lunar foothold | Land with a working cabin and establish an independent small refuge | T1-V01 Explorer; EQ25 shelter kit; Lunar Shelter Controller | Player can safely stay, walk a short loop and return. | | First descent | Read a natural entrance and survey Regolith Hollows or a Basalt Gallery approach | EQ06, EQ11, EQ13, EQ14 and EQ16 | A marked return route and protected supplies remain available. | | Homecoming and refit | Return samples and improve an existing service | Regolith Ceramic or Lunar Glass Filament applications | The Earth base benefits and the next trip involves a new choice. | An optional orbital observation sortie provides a shorter rehearsal, attractive views and useful survey practice. Its destination-specific manifest does not require a lunar shelter kit; its own cabin, supplies and protected return requirements still apply. It is not an obligatory consumable launch whose only reward is permission to craft the same vehicle again. Ground commissioning can establish basic safety; the player can then choose a supported lunar mission when its complete loadout is ready. The route deliberately allows different settlement styles. Old Valley can teach production, storage and contributions, then become the player’s preparation base. A self-built workshop can perform the same functional preparation. Authored projects provide strong examples and services without claiming exclusive ownership of the space program. ## T1-OV03 — Stable system register These identifiers are planning references. They preserve connections to the approved equipment and technology families, and let future agents report on individual systems without losing the surrounding design. An installation family can contain several physical machines. A visual subcomponent does not automatically need a separate inventory item. | ID | Working object or service | Existing family | Confirmed reference | | --- | --- | --- | --- | | T1-V01 | Explorer Rocket / Tier 1 Rocket | Orbital and Lunar capability; TEC13 and TEC14 | REF01, REF02, REF11, REF14, REF15 | | T1-M01 | Part Fabrication Table | Component production within TEC13; supplied by Earth workshops | REF01, REF10 | | T1-M02 | Rocket Assembly Station; Rocket Assembly Table reference alias | TEC13 Vehicle assembly hall | REF01, REF09, REF15 | | T1-M03 | Fuel Refinery | TEC08 Refinery and materials lab; SUPPLY01 | REF15 | | T1-M04 | Fuel Pipe | TEC14 supply connection; SUPPLY01 transport | REF15 | | T1-M05 | Oxygen Generator | TEC12 Habitat and life-support workshop; SUPPLY02 | REF15 | | T1-M06 | Launch Pad | TEC14 Launch and recovery complex | REF15 and launch scenes | | T1-M07 | Control Console | TEC14 mission preparation and service | REF15 | | T1-M08 | Storage Crate | Shared production, expedition and settlement cargo | REF15 | | T1-I01 | Rocket Part and structural component family | TEC03 and TEC13 | REF01, REF02, REF11, REF15 | | T1-I02 | Rocket Engine / Engine Module | TEC13; consumes SUPPLY01 when installed | REF01, REF02, REF11, REF15 | | T1-I03 | Fuel Tank | SUPPLY01 container and vehicle component | REF01, REF02, REF15 | | T1-I04 | Navigation Chip / Guidance Chip | Navigation and mission records | REF02, REF15 | | T1-I05 | Launch Key | Vehicle operation and ownership interface | REF15 | | T1-E01 | Tier 1 Player Space Suit | EQ23 Sealed expedition suit | REF12 and repeated suit sheets | | T1-E02 | Space Helmet | EQ23 suit component | REF12, REF15 | | T1-E03 | Oxygen Tank | EQ24 Breathing supply; SUPPLY02 | REF03, REF15 | | T1-S01 | Refill, dust service and field charging | TEC12, EQ19 and SUPPLY03 | Service need documented; detailed stations remain artwork backlog | | T1-S02 | Starter lunar refuge | EQ25; Lunar Shelter Controller | REF03 overview; construction detail backlog | | T1-S03 | Expedition Recovery Beacon mode | Existing EQ26 Communications beacon | Existing design; dedicated Tier 1 action image backlog | ## T1-M01 — Part Fabrication Table The Part Fabrication Table turns prepared basic resources into recognizable rocket components. Its dedicated reference describes an early-game machine for crafting the parts needed by the Explorer. The player chooses a component or a saved parts order, sees the stock it requires and watches a bounded fabrication operation. It adds an understandable manufacturing step between mining and a vehicle, with a useful work surface and visible output. Reference: REF10. Inputs are Earth-made structural stock, glass, prepared insulation or seals, basic circuit parts and modest workshop power where the process needs it. Outputs belong to a small component family: structural rocket parts, a nose assembly, fins, tank shells, cockpit/window fittings and engine service components. The eventual recipe set should reuse these intermediates across repairs and other equipment. A unique plate, bolt, bracket and glue item for every silhouette detail would obscure the real decisions. The confirmed asset supplies a pale surface, orange markings, heavy supports, a front mechanism and a tilted screen. The station has an accessible interaction side, an input area and a clear output position. A nearby crate may supply an authorized order. Hand loading remains practical for the first machine; automation reduces repeated transport later. Its exact block footprint must be resolved against the reference’s illustrative dimensions and normal player reach. States are unpowered, idle, missing input, ready, fabricating, output full and paused. Active orange light and restrained sparks communicate work; a label and progress form communicate the same information without color. An interrupted job retains its recorded materials and resumes or cancels through a stated recovery rule. It does not consume a complete batch again after a reload. A full output blocks the next operation safely. The table produces service parts after the first launch, so it remains useful for an established lunar program and ordinary workshop fabrication. Its high-level art is already supplied. Input/output sides, interaction reach, cancellation, accessible state cues and any final moving mechanism belong to the production and interface backlog. ## T1-M02 — Rocket Assembly Station and the table variant The assembly operation combines the prepared components into a complete Explorer. REF09 explicitly states “parts in, a rocket out” and shows a heavy platform, assembly columns and a control terminal. REF15 names a lower open bench Rocket Assembly Table. For this expansion, **Rocket Assembly Station** is the working name for complete-vehicle assembly, with **Rocket Assembly Table** retained as the source alias and visual variant to resolve. The document must expose that relationship rather than add another mandatory crafting stage. An assembly order names the recognized vehicle configuration, displays the structural and service parts required, and reserves only the materials the player authorizes. The first Explorer needs its body, cockpit, propulsion, storage and life-support services as a coherent whole. Progress is visible as staged work on a jig or a clearly presented assembly operation. It is not a single mysterious upgrade consumed behind a menu. The output is one registered vehicle with a persistent identity and an explicit handoff to its launch pad. A compact Tier 1 Rocket icon can represent that vehicle in a placement or deployment interface. It must not duplicate a second filled rocket when moved, reloaded or handed between players. The proposed first implementation transfers the completed craft within the prepared assembly/launch workflow; unrestricted field packing of a fueled, occupied spacecraft is outside this first operation. The assembly station checks for missing parts, an unavailable work area and a blocked completed-vehicle position before it commits an order. A clear placement preview identifies the actual blocks or occupied space involved. If the pad is not ready, the finished vehicle remains recorded and waiting. The player can complete the site without losing the rocket or restarting its bill of materials. Assembly also introduces commissioning: verify that a hatch can be used, a seat exists, supplies connect correctly and the chosen cargo module is installed. Detailed performance tuning stays separate from these basic functional checks. The same station later repairs or refits an existing Explorer, preserving its identity, ownership and recorded discoveries. Construction and refit obey the normal regional pause and shared-contribution rules. ## T1-M03 — Fuel Refinery The Fuel Refinery makes **SUPPLY01 Standard spacecraft propellant** from defined Earth-accessible feedstocks and power. The name and compact gray/orange machinery are confirmed by REF15; its exact chemical recipe is not. The design should present one clear game propellant for the first orbital and lunar routes. It should not require a new fuel brand for each mission, nor imply a real propulsion chemistry that the creative direction has not chosen. The player establishes a valid feedstock source, connects power, assigns a sealed output vessel and selects a batch or refill target. The interface shows feedstock required, expected propellant, processing progress and where the result will go. Any secondary output must have an explicit destination or a safe internal buffer. An unlimited invisible waste sink should not be the assumption used to make a complex recipe look balanced. The reference’s dark body, orange vertical elements and top fittings make inputs and service access easy to distinguish. A player sees the process housing, the connected tank and the transfer route to the pad. Ordinary input, propellant output and power connections need distinct shapes or labels. Status can be read from the machine face while walking through the yard. The refinery stops for missing feedstock, insufficient power, incompatible output, a full destination or a service fault. Routine faults are contained and repairable. They should create a known maintenance action rather than silently destroying the launch yard. No ordinary production order may withdraw the mission’s protected return allocation. Refinery output fills discretionary storage first or an expressly assigned mission order. Later machinery can improve throughput, energy use, storage or feedstock flexibility. The starter refinery continues to produce the same useful supply. A local Moon installation becomes an optional convenience only when its complete input chain is independently available. The first expedition brings every unit needed for its return from Earth. ## T1-M04 — Fuel Pipe and typed connections The Fuel Pipe is a visible transfer link between compatible propellant storage, refinery output and a parked Explorer service connection. Its confirmed form is a dark straight segment with orange end collars. Elbows, junctions, valves and connection states will need a production model pass, but they belong to one comprehensible pipe family. Reference: REF15. The first pipe route can be short and hand-built. Selecting a connection shows source, destination, transferred supply and the receiving limit. A service action can fill the operating tank to a chosen target, fill a protected return tank allocation, or stop. It must not continually siphon every connected vessel until a distant refinery runs dry. Connections are typed. Fuel cannot enter an Oxygen Tank because the two containers happen to share white-and-orange art. Oxygen and power services use distinct connectors, labels and compatible actions even if future universal service housings contain several ports. Invalid joins refuse the connection and explain the mismatch before a resource is consumed. A disconnected pipe pauses transfer. Stored quantities remain with their recorded containers; breaking and replacing a segment cannot multiply fluid. Valves support clear shutoff and service. Detailed pressure simulation, explosive chain reactions and long-distance unloaded networks are not required to make this first transfer meaningful. Later automation can add measured fill orders while preserving the same explicit source, destination and stop condition. ## T1-M05 — Oxygen Generator The Oxygen Generator supplies the workshop’s breathing-refill service: **SUPPLY02**, carried in **EQ24** tanks and used by the **EQ23** suit and supported refuges. REF15 confirms the machine’s name, gray cubic housing and blue front screen. Its first role is preparing a complete expedition at home, not creating an arbitrary atmosphere around every block it touches. The proposed starter process uses an explicit accessible Earth input route—an approved water-processing or atmosphere-processing recipe—plus power and the appropriate service materials. The final chosen recipe should be the same visible process used by the machine, mission planner and handbook. This chapter does not prescribe real gas chemistry. It requires that the process account for its inputs, output and any byproduct, and that the player can establish it before leaving Earth. The machine fills a compatible reservoir or portable Oxygen Tank to a selected target. Its screen shows available production input, processing condition, stored breathing supply and outstanding refill orders. A distinct service connector keeps it separate from propellant. First-time use includes filling a tank and verifying it in the suit, so the player understands that a crafted empty cylinder is not a ready expedition supply. On the Moon, an Earth atmosphere-intake mode is unavailable. A local generator needs a separately supported input recipe and actual stocked resources. The initial shelter can transfer stored breathing supply between its reservoir and carried tanks without pretending that this transfer manufactures more. Local production is a later project with a visible budget; it never rescues an impossible first-mission dependency. If power or feedstock ends, new filling stops. An occupied refuge retains its protected service reserve and warns the player before that reserve becomes inadequate. Optional fabrication cannot take the last supply assigned to breathing. Empty and full containers remain the same reusable objects with clear contents, rather than stacks of disposable differently named tanks. ## T1-M06 — Launch Pad The Launch Pad provides a registered place to position, service, launch and receive the Explorer. REF15 shows a low reinforced platform, hazard-marked edges and small corner posts. The larger scenery adds gantries and access paths. A gantry makes a good player construction project, but the first supported pad should state exactly which functional pieces are required and which are optional architecture. Placement begins with a preview of the supporting footprint, boarding access and departure clearance. The final envelope follows the resolved Explorer model. The supplied height references disagree, so a nine-block-looking illustration cannot silently become an unconditional nine-block clearance rule. Every blocking object should be highlighted directly, including player-built additions made after the rocket was placed. The pad accepts one compatible registered craft in its active berth, connects authorized services and exposes a boarding route. A player can prepare the site with crates, lamps, barriers, paths and a workshop in their own style. The launch operation affects a defined local area. Its visual plume and sound should not imply that every surrounding landscape is being physically simulated or consumed. States include vacant, craft present, servicing, boarding available, launch blocked, ready, departing and awaiting return. A returning Explorer uses a registered valid destination or an explicitly supported recovery approach. If the old pad has been removed or obstructed, the mission interface explains the alternative before committing to that arrival. A blocked home berth creates a solvable landing/recovery situation, not a lost campaign. The pad should remain valuable after the first mission: recognizable homecoming, shorter turnaround, stored loadouts and supported refits. More pads expand the player’s network through authored or self-built work. They do not cause remote factories or habitats to run when their regions are parked. ## T1-M07 — Control Console The Control Console is the expedition’s preparation and operating surface. Its wide blue screen and small worktop are confirmed by REF15. It connects information the player already understands: a particular craft, a departure site, a supported destination, a loadout and protected supplies. It should be useful before the rocket launches and after it returns. The main view starts with the intended mission. It shows the route segments, craft capability, crew seats, essentials, optional cargo, operating supply and protected return allocation. A missing helmet and a missing decorative crate are not equivalent warnings. Essentials that make the selected default mission impossible block departure and say what action fixes the problem. Optional improvements appear as choices with their benefit and cost. The console can read authorized nearby storage, create a refill order, request a component order and save a known loadout. It does not silently craft missing hardware, confiscate another player’s stock or complete an unfunded settlement project. Each action names the source and destination. A changed cargo load immediately updates the mission envelope and any resulting reserve issue. Ground commissioning uses this interface to check cabin service, fuel connections, suit readiness, route data, hatch access and a supported return location. The checks should demonstrate concrete behavior: fill a real tank, inspect a real module and board a real seat. Repeating the same completed checks on every routine departure is unnecessary; changed or damaged systems prompt the relevant check again. The console also records the last landed location, recovery-beacon association, outstanding service needs and expedition results. The player should be able to answer “what prevents departure?” or “what did we bring home?” without opening several unrelated interfaces. More detailed machine and vehicle records remain available beneath that clear summary. ## T1-M08 — Storage Crate The Storage Crate connects workshop production to mission cargo and lunar settlement. Its confirmed gray-and-orange form belongs at the fabricator, pad, cabin and outpost. The planning identity is consistent even when a mounted or packed variant is needed. Reference: REF15. A crate stores actual items and can carry a named purpose such as structural parts, first shelter, survey supplies or samples home. Saved manifests reserve quantities rather than creating a second invisible inventory. The player can see what is physically present, what is reserved for a mission and what remains available for ordinary work. Shared contributions record ownership and permission through the existing settlement system. Moving cargo onto the Explorer is a clear handoff. A selected manifest must fit the configured cargo capacity, and its mass/capacity abstraction must agree with the preparation view. The example artwork’s six slots is a useful compactness reference, not a final balance law. If the actual starter shelter and essential supplies cannot fit, the design must adjust packaging or capacity rather than require the player to abandon safe-return equipment. Unloading the first shelter leaves room for collected samples. A full return hold invites selection, an extra crate left at the refuge, or a later freight trip. Mission-critical findings are recorded independently of a fragile single item where appropriate. Storage pressure should create useful cargo choices without allowing an accidental lost specimen to erase all discovered progress. ## T1-I01 — Rocket Part and the structural family The Rocket Part icon in REF15 is a pale structural piece with dark openings and an orange detail. Other sheets name Rocket Nose, Rocket Nose Cone, Rocket Body, Core Body, Fins, Cockpit Module, Command Module, Cockpit Window, Access Hatch and Upper Fuel Tank. These are useful model and assembly labels. They are not an instruction to create a separate mandatory inventory type for every arrow in an exploded drawing. The proposed first recipe set groups structure, cockpit fittings, seals, tank structure and propulsion support into a manageable family. Components have a clear role in the finished craft and can be inspected from the assembly order. The same structural stock and service parts should repair a hatch, replace a damaged panel or support later workshop projects. A component record tracks its type, compatible configuration and any meaningful service condition. Cosmetic paint or trim does not create a stronger metal tier. Missing or incompatible components are rejected before assembly, with a direct explanation. Detailed part counts, joining animations and production meshes remain backlog, while their visual vocabulary is already supplied. ## T1-I02 — Rocket Engine and engine cluster The Rocket Engine appears as a discrete item in REF15; Engine and Engine Module appear elsewhere. REF11 makes the four-engine/nozzle cluster explicit. The first Explorer should retain that recognizable underside. Whether the recipe represents one complete cluster or several components is a gameplay packaging decision, not a requirement to expose four separately managed engine systems. The propulsion assembly consumes the standard prepared propellant within a known mission envelope. It contributes to launch, transfer and return capability under the selected travel model. The interface reports ready, unserviced, disconnected or insufficient supply. It does not ask the player to solve hidden real-world combustion or trajectory equations to understand why the rocket will not leave. Engine servicing uses Earth-available repair stock and workshop access. A bounded fault can reduce readiness or require a patch/refit at a safe site. Normal wear should be predictable enough to plan a complete first journey. A single routine trip should not secretly require an unknown lunar ore to manufacture its replacement engine. The engine remains installed in the registered vehicle record. Swapping, repairing or dismantling it must preserve its condition and the craft’s stored supplies. The exact flame shape, four-nozzle animation, service panel movement and fault presentation belong to production art and effects work rather than another concept-generation call now. ## T1-I03 — Fuel Tank The Fuel Tank is both a recognizable prepared component and the physical home of a propellant quantity. REF01, REF02 and REF15 show white/light-gray casing with orange bands or fittings. The model can distinguish installed and portable versions without changing what the supply means. A tank carries its contents, capacity, compatible supply and reserve assignment. Filling transfers measured game quantities from a real source. Emptying or replacing a tank never duplicates contents. A craft may use separate visible vessels or one capacity divided into clearly protected allocations; either approach must make the reserved return portion understandable in the preparation view and cabin. The player can service a tank on Earth, connect it to the pad or carry a compatible replenishment vessel when the cargo plan permits. A return allocation cannot be automatically consumed by a refinery, workshop or optional detour. Deliberately changing it is a specific mission revision with the consequence shown before the action. The same fuel system remains useful after lunar refits. Better insulation or storage may improve operations without changing every old container into obsolete junk. Final size, ports, installed location and interaction animation remain model work; exact capacities await the real starter cargo and travel loop. ## T1-I04 — Navigation Chip / Guidance Chip REF15 calls the blue-centered item Navigation Chip; REF02 calls its counterpart Guidance Chip. This expansion uses **Navigation Chip** as the working label and retains **Guidance Chip** as the searchable reference alias. It is one functional role until a meaningful reason to separate navigation and control hardware is actually designed. The chip is built from accessible Earth circuit materials and stores or enables the Explorer’s supported route information. It is not a consumable ticket to the Moon. The initial lunar route can be prepared through the Earth survey/observatory service and confirmed mission data without demanding a sample from a place the player cannot yet reach. At the console, it identifies the recognized vehicle configuration, available routes and the latest valid landing/return records. Later surveys add supported sites and better route knowledge. The chip does not reveal every underground room or replace the player’s local exploration. Navigation records remain recoverable through the player’s established survey history if the physical hardware is lost. Missing or incompatible hardware prevents the relevant launch plan and says why. A replacement can be made from already reachable resources and restored from recorded data. Detailed chip sockets, screen graphics and any distinction between installed hardware and copied route records belong to the interface/model backlog. ## T1-I05 — Launch Key The Launch Key is a reusable physical control item with the bright orange head shown in REF15. It creates a satisfying deliberate action at the console or cockpit. It is not a rare single-use resource that must be recreated for every routine launch. A key is associated with an authorized vehicle or launch service under the world’s ownership rules. Possessing its icon does not grant access to another player’s supplies or override shared-project permissions. Replacement and delegated operation are available through an authorized local service so that losing an item cannot permanently disable an otherwise working space program. Turning or presenting the key requests departure after the mission checks have passed. It does not bypass a missing suit, an occupied clearance zone or a depleted protected reserve. The short final sequence gives participants time to cancel or finish boarding. The key then remains with its owner or in the declared control position according to the chosen interaction design. Exact hand animation and key-slot model are later production tasks. ## T1-E01 and T1-E02 — Player Space Suit and Space Helmet The confirmed Player Space Suit is the first implementation of **EQ23 Sealed expedition suit**. The Space Helmet is part of that system, not a second armor line. REF12 establishes pale panels, dark blue glass, orange bands, dark gloves and boots, a simple chest control panel and integrated life-support pack. Its material analogies describe appearance; they do not require the player to obtain decorative quartz or terracotta as the only way to seal a helmet. The complete suit supports the planned lunar surface and early underground environment when it has breathing supply, appropriate power and maintained seals. The helmet alone does not make an otherwise unprepared player safe. A service view checks the outfit as one understandable system and identifies an absent or faulty part directly. Inventory arrangement should avoid forcing the player to inspect six independent hidden durability bars during a retreat. The main operating indicators are breathing reserve, available equipment power and protection/service condition. They are context-sensitive and use icons, text and optional audio as well as color. A tank warning should say how it affects the current return plan. Dust on joints or seals provides a visible reason to use the service point, with a predictable tolerance before a field problem becomes serious. Suit assembly and repair use the existing textile/seal and habitat workshops, prepared glass, basic fittings and accessible insulation. The player commissions the suit on Earth by connecting a filled tank, checking its status and using a safe test/service action. That exercise teaches the difference between protection hardware, stored supply and refill infrastructure before the Moon turns the distinction into danger. The suit supports normal building, tool use, inventory work, tethers and sampling. Its protection does not confer unlimited exploration time or automatic immunity to every later planet. Lunar refits can improve dust servicing, instrument integration or comfortable operating duration without requiring a new identity for every palette variant. Removing the helmet in a supported breathable refuge is allowed and clearly reflects the refuge’s real service state. In exposure, equipment changes warn against the specific problem before a destructive action completes under the default settings. Deliberate risk remains possible through the game’s chosen interaction rules. Exact equip animations, tank attachment and consistent chest-panel indicator mapping remain backlog; reference views vary in those details. ## T1-E03 — Oxygen Tank and breathing reserve The Oxygen Tank in REF15 implements the portable side of **EQ24 Breathing supply** and contains **SUPPLY02**. It uses the same readable pale-and-orange family as the suit while remaining visually and functionally distinct from Fuel Tank fittings. The O₂ cylinders in REF03 provide an additional mounted-storage reference. The tank is refillable. Its record includes stored breathing supply, capacity and condition where condition has a meaningful service consequence. The suit, shelter and workshop display the same quantity through a consistent reserve language. Transferring supply between them is explicit and conserves the recorded amount. A field tank buys a known operating envelope. A small emergency allocation supports a retreat, a repair or beacon recovery; it should not be silently spent by optional tools. A spare tank may be carried or cached as part of a visible route plan. Refilling from a refuge uses that refuge’s actual discretionary storage and protects the reserve assigned to its occupied life-support service. The first expedition carries its complete expected supply and contingency from Earth. Exploration can extend when the player builds a supported refill chain, brings more stored supply or shortens the travel loop. It does not extend because a decorative Oxygen Generator was placed on an airless surface without input. Final capacities should be tuned with actual walking, building and underground detour times. ## T1-V01 — Vehicle layout, cabin and use The Explorer should be recognizable from the supplied silhouette at every stage: assembly, pad, launch, lunar landing and homecoming. The stepped nose, square dark window, orange bands, low access hatch, four fins and dark cluster establish its identity. REF11 provides a detailed exploded view; REF01 and REF02 show the cockpit and cargo experience. The final production mesh must resolve these views into one usable form. The references disagree on height: approximately six, nine and twelve blocks all appear. The plan therefore keeps final dimensions unresolved. A model pass must test boarding reach, interior space, pilot view, hatch operation, landing stance, collision, cargo access and launch clearance together. Selecting a nice exterior number while silently adding an impossible interior would not solve the issue. The proposed starter configuration supports one pilot, following the compact reference UI, with a real seat, clear forward view, understandable control position and a small pressurized cabin refuge. Exact cargo capacity remains adjustable until the full safe starter manifest has been packed. The example six-slot UI is evidence of intended compactness, not permission to exclude the shelter or return reserve. Additional passengers require genuinely supported seats, supplies and space; a player cannot travel as an unrecorded crate. The cabin provides a safe place to check equipment, recover from a short surface sortie and prepare to return while its services are functioning. A full comfortable sleeping/workshop arrangement may belong in the deployed shelter rather than be forced into an unresolved hull. The old Pilgrim description’s home-like qualities can appear through exterior lamps, accessible storage, a clear entrance and the immediate refuge built beside the Explorer. Rocket use follows recognized modes: parked, serviceable, boarding, mission ready, launching, passage, approach, landed and return preparation. Local control is limited to supported operation. The first release need not promise arbitrary moving player-built voxel houses, a seamless astronomical simulation or unrestricted atmospheric flight merely because the launch art is dramatic. The player can walk around the parked craft and identify its hatch, service points, cargo access and engine region. From inside, the interface emphasizes destination, cabin condition, supplies and current action. During an authored passage, players can enjoy cabin presence and views; established travel also supports a shorter presentation. Progression should not demand hours of passive waiting between useful decisions. ## T1-S01 — The service point and field-power relationship A service point groups several existing functions: suit check, dust cleaning, tank refill, minor repair and field-cell charging. It belongs to TEC12 and the existing workshop families. It need not become five new mandatory machine blocks in Tier 1 merely to give each interaction a separate icon. Earth service can draw from stocked workshop inputs and established power. The first lunar version begins as a compact part of the shelter or an accessible service rack. It refills from real carried reserves, charges from its actual supported supply and uses a bounded stock of repair materials. The player sees what is available before leaving for a longer route. Field cells use **EQ19** and **SUPPLY03**. Lamps, survey tools and supported suit services should share a coherent charge/refill vocabulary. Charging an optional tool cannot steal the last allocation needed to keep an occupied refuge safe. Stored batteries do not silently decay while the region is parked under the approved default direction. The service experience is quick enough to become a satisfying expedition ritual: unload samples, brush or service seals, connect tank, swap a cell, inspect the next route. Later automation can prepare a saved loadout and reduce repeated handling. Dedicated rack models, dust states and refill animations remain clearly labelled detailed-artwork backlog. ## T1-S02 — Starter shelter and the lunar outpost The first lunar mission carries **EQ25 Shelter kit** from Earth in addition to its working cabin. The player may retreat to the Explorer while placing it. No lunar ore, uncertain buried resource or locally manufactured fuel is required to create the first breathable sleeping cell. The **Lunar Shelter Controller** follows the approved staged-construction system. Its first operational stage is a powered airlock and protected sleeping cell. The player selects a supported plot, previews the structure, contributes materials and watches bounded construction. Suitable generated arrival sites offer a feasible footprint without forcing one exact architectural position. Free building around the shelter remains available. Later stages add the dust porch, small workshop, storage and optional Basalt Gallery enclosure. Each stage adds a usable service and a visible change. Sealing an enormous player-dug chamber is not assumed to work through one magic block; the supported enclosure rules, required boundaries and service capacity must be communicated before construction begins. REF03 already provides the overview image: white/orange habitat, warm light, dish, mast, storage, utility equipment, rocket and Earth above a gray crater landscape. Detailed construction-stage and interior art are backlog. The outpost should stay small enough that the natural Moon remains the dominant setting, while giving the player unmistakable evidence that the place has become a home. ## T1-X01 — Departure, readiness and the first flight The first mission planner presents a supported lunar destination, a conservative arrival site and the complete journey back to Earth. Essential readiness covers the Explorer’s configuration, working cabin, filled propellant and breathing supply, valid suit, charged field equipment, starter shelter, usable cargo access, navigation data and a supported recovery association. An ordinary local repair kit is included in the recommended manifest. Preparation distinguishes the expedition’s ordinary operating budget from its protected return allocation and a small emergency allowance. Food, lighting, tethers, markers, survey equipment and sample containers are plainly listed. Optional decorative cargo or a larger observatory batch appears separately as a choice. The player can understand the consequence of exchanging cargo before the pad locks in departure. The final sequence checks who is actually aboard, closes and verifies the supported cabin, confirms pad clearance and accepts the Launch Key action. It offers a brief cancellable interval with clear local sound and light. Launch has weight: ignition, force, plume, departing terrain and the changing view of Earth. The spectacle uses the confirmed visual family and does not require the player to solve an opaque piloting minigame on their first departure. An active mission record prevents partial handoffs. Reloading between launch and arrival resumes a recognized state with the same craft, passengers, cargo and supplies. It cannot create both a landed copy and an in-flight copy. Multiplayer departure only includes recorded participants and supported seats; people still working at home remain at home. A disconnect is handled by saved mission state and the established absence rules, not by a surprise unattended life-support death. ## T1-X02 — The first lunar walk and descent The opening lunar loop begins at **MO-S1 Earthrise Rim**. The landing site has a readable shelter location and a feasible walking route to a first geological interest. It offers the emotional view of Earth, broad gray shelves, clear shadows and occasional meaningful drops. A large dramatic chasm can be visible without lying between the player and their first refuge. The player opens the hatch, checks suit status, places a return marker and transfers the starter shelter crate. Construction establishes the sleeping cell and airlock while the Explorer remains an independently usable retreat. A short surface survey teaches navigation and confirms a natural entrance. The player returns once before committing to a longer underground trip, making the relation between time, supplies and distance concrete. The next sortie reaches **MO-L1 Regolith Hollows**. Tight fractured spaces, dust shelves and short tethered descents ask for careful movement and a visible route home. Cracks and falling particles warn of bounded instability before extraction or traversal. The default first route allows a conservative approach with Earth-made anchors and ordinary useful tools. A broad **MO-L2 Basalt Gallery** approach supplies the first great underground contrast: dark scale, a sweeping tube shape, a roof opening or a natural junction that makes mapping worthwhile. The expedition can take samples, record a route and return without fully conquering the deepest Moon in one sortie. The intended reward is both a material and a remembered place. Sound and feedback reinforce the suit experience: breathing, transmitted contact, radio and connected machinery. The Moon remains predominantly lifeless. Routine creature combat is not added to create arbitrary activity between the shelter and the cave. The player’s preparation, construction and interpretation already provide the encounter. ## T1-X03 — A sustained Moon campaign Tier 1 continues beyond planting a flag. **MO-S2 Shadow Basin** supports a darker navigation route, reflective markers and deliberate use of portable light. **MO-L3 Glassfall Vaults** adds fragile impact-glass formations, ledges and careful instrument movement. Improved anchors and better route knowledge let the same Explorer support a more ambitious second expedition. **A Light Across the Basin** gives that learning a project: connect natural vantage points through reflectors and protected relay instruments, then use the results at the **Rim Observatory Controller**. The objective is reliable observation and route-making. Its devices do not need to be reimagined as an alien temple or a new mandatory species of exotic power crystal. Regolith Ceramic begins with accessible surface feedstock and a supported processing plan. Lunar Glass Filament rewards geological sampling and careful extraction. The first samples can return to Earth for processing. A lunar workshop later reduces hauling and makes local construction more convenient. These choices distinguish a brief scientific trip from building a lasting outpost. Neither material is the ingredient that suddenly makes the stranded first rocket work. They improve habitat panels, light guides, sensors and instruments for future trips and Earth use. Deeper Moon progress depends on preparation and understanding; it does not make the Explorer obsolete immediately after its first landing. The Moon should remain somewhere the player can choose to maintain a workshop and a view. ## T1-X04 — Return, servicing and useful refits Return preparation begins while the player is still at a refuge. The console or cabin shows the recorded Earth destination, protected propellant, breathing allowance, crew, cargo and current service state. Samples are loaded into real storage. Unneeded local construction supplies can remain in marked crates at the outpost, preserving a useful reason to return. Before departure, the player parks the managed shelter in a coherent saved state. With no eligible participants remaining, its authored consumption, production, construction and events pause according to the regional rules. Its stocked goods stay recorded. If another participant remains, that occupied region continues under its ordinary active service budgets; a departing owner does not freeze a teammate’s functioning habitat. Homecoming uses the existing pad or a supported alternative arrival. Unloading feeds the workshop, survey record and later construction orders. The results page connects each discovery to a practical next option: a compact cave-light upgrade, a sealed workshop panel, a better survey component, another observatory instrument or the next lunar shelter stage. Refits should change a useful property while keeping the Explorer recognizable. Suggested lunar refits improve dust service, instrument integration, storage organization or thermal endurance. They use a material the player has already brought home or can safely access on a repeat trip. Bigger mission cargo may trade against another advantage. A later craft is desirable for a new capability, not merely because every existing Tier 1 service was invalidated. ## T1-S03 — Recovery, reserves and failure The supported recovery device is the **Expedition Recovery Beacon mode of EQ26 Communications beacon**. It is not a second compulsory beacon recipe. Before the first lunar departure, the player establishes a recoverable association with the craft, starter refuge or approved return service. The interface explains what that mode can do under the selected difficulty. Low supply, a blocked route, a damaged service part and a disabled craft are different problems. A low tank normally calls for retreat or a planned reserve. A lost path can be recovered with markers and a beacon location. A bounded equipment fault can use EQ27 repair stock. A disabled Explorer may require the recovery service and later salvage. The design should offer a next action rather than collapse all failures into instant total loss. Recovery may spend emergency stores, take an active in-game interval or leave nonessential cargo for retrieval. It preserves discovered navigation, learned recipes, completed story milestones and access to the next required progression step. A unique survey result should not disappear because its only physical copy fell through an inaccessible crack. Recovery is bounded assistance, not free routine transport or an unlimited supply source. Protected reserves are actual allocations with ownership and purpose. Automation cannot raid them. Reassigning them is a deliberate mission change with the resulting limitation shown. A player taking an optional risk sees what they are choosing. The default plan must remain safe without requiring the player to exploit recovery as its intended refuelling method. ## T1-B01 — Balance and the shape of industry The production chain should feel substantial because the work has visible purpose. Metalworking supplies frames and fittings; ceramics insulate and contain; textiles and seals make protection possible; power runs tools and refills; fabrication makes parts; assembly produces a vehicle; the pad and console turn it into an expedition. Each stage creates a capability the player can understand and reuse. The first small installation should be practical to supply by hand. Expansion rewards better throughput, storage, convenience or resource efficiency, with actual costs in space, power, feedstock or service. Adding a larger processing train must not always be the best answer for every player and every resource. A lunar field workshop may favor compactness and reliability while the Earth base handles bulk work. Balance should protect the relationship between exploration and manufacture. The player explores to find materials, routes and knowledge; industry prepares and improves the next trip. Industrial breadth should not let one early machine multiply every ore into endless universal stock, replace all surveying or eliminate the reason to revisit places. Conversely, one poor random vein should not prevent an otherwise prepared world from reaching its first launch. The main costs to tune together are the starter bill of materials, total workshop effort, refill effort, travel operating envelope, useful cargo, expected sortie duration and recovery allowance. Requiring frequent resource sorting or many idle waits is not the same as requiring planning. A good Tier 1 balance pass observes whether players understand their machine layout, can diagnose a stop, have enough room for the safe starter manifest and return with a reason to build again. ## T1-D01 — Information, states and regional persistence The player-facing information model starts with objects and actions: this machine is waiting for a tank; this crate contains shelter parts; this reserve is assigned to return; this habitat is occupied; this pad is blocked by the highlighted structure. Stable internal identifiers support those statements without being shown as programming jargon in ordinary product screens. Each placed machine records its identity, supported configuration, orientation, connections, physical inventories or reservoirs, active order, completed progress, output claim and service state. Each Explorer additionally records its installed modules, crew, location or travel stage, mission route, cargo, supplies, reserved allocations, ownership and recovery association. Reference-image IDs link production decisions back to the approved art. All authored work follows the approved regional eligibility boundaries, including horizontal area, vertical bounds and dimension. A player directly above a lunar factory in some unrelated space is not automatically operating its region. Paused work retains its state without an offline catch-up penalty. Ordinary Minecraft systems outside these managed features retain their established behavior. On resumption, an order completes once, a transfer arrives once and a mission occupies one supported state. Recorded cargo and supplies remain conserved through loading, unloading, cancellation, construction and recovery. Those are substantive implementation requirements because the whole expedition depends on trusting the quantities the interface displays. ## T1-A01 — Art coverage and explicit future work All fifteen supplied images remain in the reference gallery with their original visible labels. The document uses REF15 for the Tier 1 system overview, REF09 and REF10 beside the two manufacturing roles, REF11 beside the Explorer, REF12 beside the suit and REF03 beside the first lunar foothold. Other sheets remain accessible as supporting angles, interior examples, journey boards, environment atmosphere and later-tier references. Repeated subjects are useful references, not missing new artwork. The confirmed high-level visuals are already sufficient for this slice. Detailed artwork backlog includes final model scale; a consistent rocket/suit turnaround; geometry and UV production; component sockets; hatch and boarding action; usable cockpit/cargo layout; machine port layouts; assembly stages; pipe variants; refill and dust-service actions; suit/tank attachment; launch/landing effects; shelter stages and interior; and recovery-beacon operation. Each future commission should point to the corresponding T1 identifier and a specific unresolved production need. The reference conflicts remain visible: six/nine/twelve-block rocket scale; table/station form and naming; Navigation/Guidance Chip; example recipes and cargo figures; varying chest-panel colors; and differing embedded brands. They are decision records, not reasons to discard the user’s concepts. SUBSTELLAR remains the surrounding project identity. No further Tier 2 or Tier 3 generation or full system expansion is included in this first Tier 1 slice. ## T1-A02 — A concrete first playable implementation slice The first implementation target is one complete Earth–Moon–Earth loop using a coherent subset of this full design. It includes the two manufacturing roles, explicit fuel and breathing preparation, one working Explorer, a serviced pad and console, suit/tank use, packed shelter, a conservative generated arrival, one surface route, one shallow descent, sample return and a usable home benefit. It demonstrates why the machines exist rather than presenting an isolated launch cinematic. Acceptance requires that the entire default journey can be prepared from already available Earth resources; essential cargo genuinely fits; the player can identify missing inputs and blocked operations; protected return supplies stay protected; a first shelter works before local extraction; and interrupted travel or paused regions preserve the same craft, people, stock and progress. A player who makes a recoverable mistake can explain both the problem and the next useful action. The following expansion can add deeper lunar variants, a larger observatory chain, local processing alternatives, more refits, shared expedition convenience and richer service animation. The reference gallery and the complete written system stay ahead of that implementation. They provide the whole direction while making the first deliverable finite and testable.