# Tier 1 — Model and Implementation Specifications ## T1-SPEC-01 — Purpose, authority and current technical status This specification converts the confirmed Tier 1 visual family into a coordinated production plan. It adds proposed dimensions, interfaces, assembly boundaries, operating states and implementation tasks to the existing Tier 1 chapter. It does not replace the supplied images or turn their example numbers into approved recipes. Every original reference remains part of the direction. The Explorer remains one physical first spacecraft supporting orbital and lunar missions, including a dependable return to Earth. Keel and Pilgrim remain preserved earlier concepts rather than extra compulsory first-tier vehicles. The available project material for this slice consists of the creative direction, its HTML source, registers and supplied artwork. No Minecraft mod source project, Java implementation, Gradle build, selected loader or confirmed target game version was available in this workspace. Consequently, the geometry below is a design proposal; cabin fit, collision behaviour, rendering, networking, persistence, recipe balance and performance have not been verified in-game. A future project inspection must identify the actual implementation and its constraints before BUILD. Updating this document and its register does not authorize mod development. The production register contains twenty canonical asset or service roles: T1-V01; T1-M01–M08; T1-I01–I05; T1-E01–E03; and T1-S01–S03. Service roles may be provided by an existing host rather than a new block. Their identifiers describe durable responsibilities. Mesh pieces, inventory items, saved objects and user interfaces need not have a one-to-one relationship. A four-nozzle engine cluster can be one installed module, and a service rack can expose several existing functions without adding several mandatory recipes. All first-launch essentials remain manufacturable from reachable Earth inputs. No lunar product, deep Core material, Heartglass, rare creature drop or advanced planetary plant becomes a hidden prerequisite for the cabin, suit, shelter, fuel or return. The original equipment and supply identities remain authoritative: EQ23 suit, EQ24 breathing supply, EQ25 shelter kit, EQ26 communications beacon, EQ27 repair stock, EQ19 field batteries, and SUPPLY01–SUPPLY03. This document defines how those responsibilities meet the approved appearance. ## T1-SPEC-02 — Evidence, source conflicts and the two review choices REF15 provides the strongest combined inventory of the rocket, named items, machines, suit and complete round trip. REF09 directly identifies the Rocket Assembly Station; REF10 directly identifies the Part Fabrication Table. REF11 supplies an exploded rocket, four-nozzle underside and open hatch. REF12 anchors the suit, backpack and palette. REF01 and REF02 show cockpit and cargo intent; REF03 shows the small lunar refuge. REF08 and REF14 provide additional orthographic and scale references. Those sheets were visually inspected for this specification. The existing catalogue preserves the other supplied views and later-tier references. Evidence strength is recorded by claim. An explicit printed object name is direct naming evidence. Repeated silhouette details are strong visual evidence. A depicted interior establishes an intended experience, while leaving its actual dimensions unresolved. A printed number marked example or approximate is illustrative evidence. New port coordinates, tolerances and animations below are proposed engineering allowances. Repetition across several generated views cannot itself prove a mechanically consistent model. | Review choice | Recommended default | What remains open and when it matters | | --- | --- | --- | | T1-DEC01 — Explorer scale and usable cabin | Test a nine-block total height, three-by-three main body and five-by-five maximum fin envelope. | Review a measured mock-up before final geometry and textures. Six, nine and twelve blocks appear in the references. If cabin, airlock, supplies, access or silhouette fail the test, revise the shell deliberately; do not hide the failure behind an oversized interior. | | T1-DEC02 — Manufacturing station form | Keep a visibly smaller Part Fabrication Table, using REF10's work surface and short supports; use REF09's broader column station for complete-vehicle assembly. | Confirm the distinction before final station models. REF01 and REF15 supply lower bench variants. They remain useful references and do not create a third compulsory workstation. | These are the two creative choices requiring user review before final asset production. The remaining details are recommended working defaults that can be adjusted through documented fit tests. The working names stay Part Fabrication Table and Rocket Assembly Station; Rocket Assembly Table is a source alias for the latter. Navigation Chip and Guidance Chip remain one role. No production model should acquire an unapproved TENFOLD, HORIZON SPACEWORKS or other source-sheet brand simply because that mark appears in an illustration. SUBSTELLAR is the project identity; originals remain unchanged. ## T1-SPEC-03 — Coordinate and measurement contract Every freestanding production asset uses the same local frame. One block is the unit of length. The origin is the centre of the reserved footprint at its lowest placement plane. Positive Y points upward; positive Z points out of the designated front; positive X is the asset's right when looking outward through that front. A player standing in front and looking at the machine therefore sees positive X on their left. Width is X, depth is Z, height is Y. Bounds are stated as minimum and maximum XYZ triples, inclusive as geometric surfaces rather than extra occupied cells. For a footprint W by D, the placement reservation extends from minus W/2 to plus W/2 in X and minus D/2 to plus D/2 in Z. Even-sized structures use the corresponding half-cell placement centre; their block-aligned footprint is still explicit. The controller anchor identifies the lowest front-left footprint cell, meaning the cell at negative X and positive Z. It stores the structure origin and facing; it does not substitute that corner for the model's origin. Moving a controller visually cannot silently move the registered footprint. Horizontal placement accepts four quarter turns. At zero degrees local +Z becomes world +Z; at ninety degrees it becomes world +X; at one hundred eighty it becomes world −Z; at two hundred seventy it becomes world −X. The ninety-degree transform is (x, y, z) to (z, y, −x). All ports, approach boxes, collision pieces, component sockets and previews use that same transform. Translation follows rotation. Arbitrary tilt is outside the initial grounded machine and landing-site contract. A port coordinate marks its connection centre and an outward normal marks its physical facing. Resource direction is separately labelled input, output or controlled transfer; the normal is not a flow arrow. Item insertion sockets inside a chassis are identified as internal interfaces. Wearables use the same axes in their neutral standing pose, with the origin at the player's feet; attachments then follow named body anchors. Inventory display models use their own listed small bounds and become installed through an explicit transform. World position, installed position and inventory icon scale must never be inferred from one another. ## T1-SPEC-04 — Geometry, materials, textures and readable detail The shared appearance is pale white and light gray structural casing, restrained terracotta-like orange bands, dark mechanical parts, navy glass and focused blue screens. REF12's material names are visual analogies. They do not require quartz or decorative terracotta to be the only valid recipe inputs. Orange identifies service fittings, handling corners and important bands. Black/yellow stripes belong around the main hatch and controlled launch edges. Preserve the stepped rocket taper, square window, low hatch, four fins and four-nozzle underside before adding small panel detail. The proposed baseline is a coherent sixteen-texel-per-block surface density for ordinary world geometry, with a separately budgeted denser region only where a tiny symbol must remain readable. This is a production starting point, not a verified engine limit or demand for a particular texture-file size. Atlas dimensions should follow actual surface area, batching requirements and the eventual renderer. Large files should not be selected merely because the source image is detailed. The suit follows the actual player rig and texture conventions discovered in the project audit; its panel rhythm should match the rest of the family even when its mapping differs. Keep broad material blocks legible at ordinary play distance. Model silhouette changes, hatch recesses, supports, collars and major vents. Use texture for fine seams, rivets, mild wear and labels. Avoid baked directional sunlight, baked launch flames or ambient shadows that disagree with the world. Dirt belongs mainly at lower edges, touched fittings and service joints. More detailed REF04/REF05 weathering is an atmosphere target, not an automatic requirement for every small item. Screens require a readable unlit state and restrained active areas; illumination support remains conditional on the chosen rendering implementation. Deliver production parts with semantic names such as hull_lower, hatch_outer, ladder_inner, tank_service_cover, fin_front_right and nozzle_rear_left. These names are conventions for source assets, not required Java or engine APIs. Exported assets must retain editable sources, texture maps, origin markers, collision sketches and a reference note. First-person equipment must leave the central view and tool interaction readable. Surface markings and important states must also work with reduced effects and without an enhanced shader presentation. ## T1-SPEC-05 — Explorer dimensions and the cabin fit gate The proposed Explorer test model has a three-by-three main shell, a nine-block total height including antenna, and a maximum five-by-five silhouette across the four diagonal fins. Its local origin is at the lowest parked vehicle contact plane. Main-shell bounds are X/Z ±1.5; maximum fin bounds are X/Z ±2.5; total Y is 0–9. These are separate envelopes. A single solid five-by-five-by-nine collision box would make the hatch, fin gaps and cabin unusable and is specifically rejected. A candidate vertical arrangement reserves Y 0–1.5 for propulsion and supporting structure; a lower vestibule floor at Y 1.5; a pressure partition from Y 3.625 to 3.875; an upper cabin floor at Y 3.875; usable upper headroom to at least Y 6.0; and a nose, non-occupied equipment space and antenna above. The working internal envelope is 2.25 by 2.25 blocks. Each occupied level must retain at least 2.125 blocks of clear standing height where standing is required. Those allowances are a test layout, not evidence that every installed tank and structural member already fits. The exterior front doorway is a proposed one-block clear width by two-block clear height, from Y 1.5 to 3.5 at Z +1.5. A three-step boarding element rises from the support surface and aligns with that opening. An outward-opening hatch uses a separately checked sweep; the central approach stays clear of the diagonal fins. An internal pressure hatch at the rear ladder separates the vestibule from the upper cabin. The two closures are interlocked during ordinary airlock cycling. The outer door can open while the occupied upper cabin remains isolated; changing a texture or displaying a green icon is insufficient to establish that result. The upper space must fit one supported pilot seat, accessible controls, a forward view through the visible window, a standing/egress position and access to the ladder. Cargo storage and actual supply housings occupy declared non-walkable spaces. Fuel and breathing capacities are game quantities, but their model housings cannot simultaneously occupy the player's body or a door sweep. The seat, ladder, closures, backpack clearance, cameras and access to every required service must be checked with the actual player rig. If any essential function fails, T1-DEC01 reopens. A larger shell is preferable to deleting the working airlock or inventing an unannounced expanded interior. ## T1-SPEC-06 — Explorer components and authored assembly The Explorer is divided into authored components with stable attachment responsibilities. The lower propulsion assembly contains four visible nozzles but one initial managed engine-cluster role. The body carries structural panels, defined tank housings, the lower entrance and cargo/service access. The upper cabin carries the seat, window, control position and pressure boundary. The nose carries its stepped casing, antenna and permitted instrument space. Four fixed fins retain the diagonal arrangement seen from above. The initial design does not add retracting wings or an unfolding vehicle that the references never establish. A component may require more than one physical mesh. The exterior hatch leaf, hinges, closure indicator and collider belong to one hatch assembly. The inner pressure hatch is a new functional part justified by the required cabin, with its appearance derived from the same family. A Fuel Tank item can install into a larger authored housing through a declared mapping; it is not assumed to remain an unchanged half-block inventory cylinder. Cosmetic covers cannot be harvested as extra valuable components every time the vehicle is reloaded. The proposed assembly presentation has six committed stages: reserve an authorized parts order; complete the lower frame and engine cluster; install the tank and main structural modules; install the cabin, window and inner pressure assembly; attach the nose, fins and exterior services; then commission the finished craft. Temporary supports and tool motion may change within a stage. The authoritative stage and deposited material totals change only at defined commit points. A cancelled unfinished job returns recorded uncommitted stock and exposes the policy for already-built stages before cancellation. Each stage has an inspectable useful result. The player can identify an absent engine, missing window or unconnected life-support module directly. Part counts and processing durations remain balance records rather than dimensions hidden in a model. The finished Explorer receives one persistent vehicle identity, associated modules and a single current location. Servicing an existing craft returns it to a controlled assembly state without granting a second vehicle item. Refitting retains that identity and its discoveries. The first production handoff includes an assembly-stage list, visible part list and commissioning sequence so an artist and an implementation agent can work from the same boundaries. ## T1-SPEC-07 — Landing, launch and service space The initial pad proposal uses a seven-by-seven deck. Its local origin is at the centre of the deck's lowest foundation plane; the deck top is Y 0.5. The Explorer is placed at pad-local (0, 0.5, 0), with matching facing, so its antenna reaches pad Y 9.5. The deck encloses the five-by-five fin envelope with one block of surrounding deck on every side. A nine-by-nine controlled site, X/Z ±4.5, reserves the immediate approach and service area. Decorative towers and storage can be built beyond it, subject to the actual departure checks. The first lunar landing uses a surveyed natural landing site, not a previously constructed Launch Pad. Its registered contact plane becomes the Explorer origin directly, with no half-block deck offset. The same hull, support, approach and departure-clearance checks apply to the supported ground landing. Actual contact shapes and acceptable slope require the measured model pass. A suitable first arrival must supply this viable terrain and the nearby starter-shelter plot. The player returns using carried supplies and onboard controls; a local pad, refinery or external console is not an arrival prerequisite. A later built pad adds repeatable services and convenience. During service, proposed low folding couplers may rise to pad Y 3.0 and connect to the rocket's declared sockets. They are a new production detail derived from the connection requirement, not a confirmed part of REF15. They retract into the deck before departure. Accordingly the pad record distinguishes its half-block deck from its three-block maximum service-pose height. Raising a coupler is blocked if its swept space is occupied; it does not shove a player aside. The normal flight-clear state contains no raised service equipment. The front boarding approach reserves X ±0.5, Z +1.5 to +4.5, and sufficient height to reach the doorway, measured in rocket-local coordinates before the pad translation. The lower stair and open-hatch sweep must be reconciled in the fit model. Wider ordinary walking space is desirable around that required strip. Any outward hatch or panel sweep is part of the operating clearance, even though it is not part of the closed hull bounds. Fins use authored collision pieces inside their visible volume, leaving the cardinal front route usable. For the proposed vertical departure, validate a seven-by-seven clear column above the deck through the local ascent presentation and to the defined transition boundary. The actual boundary must be selected after inspecting the world's height and travel implementation. No invented fixed altitude is assumed here. Only the active craft and explicitly retracting approved service parts may occupy their managed pre-launch positions. A roof, overhang or tower crossing the column blocks departure and is highlighted. Landing tests the same footprint, support, approach and headroom before committing a destination. A changed or blocked Earth pad invokes the supported alternate-arrival process while preserving the craft and return plan. ## T1-SPEC-08 — Part Fabrication Table production specification T1-M01 remains the **Part Fabrication Table**, mapped to IND-M02 and component production within TEC13. The recommended footprint is two by two blocks, with a maximum height of two blocks for its short supports and angled screen. Its pale work surface, orange accents, dark base, front mechanism and useful screen follow REF10, while REF01's lower bench remains a recorded variant. The worktop sits around Y 1.0. A one-block front access strip and half-block side service allowance keep ordinary hand operation practical. The proposed input tray is on the negative-X side at (−1, 0.75, 0); the output tray is on positive X at (1, 0.75, 0). A rear power inlet is at (0, 0.5, −1). The front screen's interaction centre is at (0, 1.25, 1). These coordinates are connection or interaction anchors, not a demand for a particular pipe or inventory API. The allowed first automation is an explicitly authorized adjoining buffer or supported local transfer endpoint. Being physically adjacent does not automatically grant access to another player's crate. The machine's visible subassemblies are the base, worktop, input/output trays, short supports, front mechanism and terminal. The first activity animation uses a small clamp or tool movement over the surface, restrained work particles and a visible in-progress component. It must fit the reserved volume and should not animate an enormous rocket appearing on a two-block table. Ordinary idle state retains the empty or staged work surface. Missing input points to the empty input area; a full output indicates the obstructed collection position. The order record identifies component type, authorized stock, stage and output reservation. Loading, interruption, cancellation and output collection conserve those quantities. Reduced-animation mode preserves the same state label and completion feedback. Acceptance requires that a player can supply a component order by hand, read what is missing, distinguish waiting from active work, collect exactly one completed output and resume an interrupted batch without paying twice. Final recipe counts, power draw and throughput are deferred to the first connected industry balance pass. ## T1-SPEC-09 — Rocket Assembly Station and vehicle handoff T1-M02 remains the **Rocket Assembly Station**, mapped to IND-M46 and TEC13. The recommended machine footprint is three by three blocks, height two, with the broad pale platform, dark footings, orange/gray columns and blue terminal of REF09. Its normal full work area is five by five, including a one-block access perimeter. REF15's lower Rocket Assembly Table is retained as an alias and variant. It does not become another required machine between fabrication and the completed craft. A three-by-three, two-block-high station cannot physically contain a five-wide, nine-tall assembled Explorer. The proposed workflow therefore treats it as the assembly controller and jig, with the vehicle stages erected in an explicitly linked vacant Launch Pad berth. This is an authored assembly installation consisting of the station and a prepared vehicle work position. The station never displays a full-size rocket intersecting its columns. Parts and small subassemblies can appear on its work surface while corresponding committed stages appear at the berth. For the first implementation plan, the linked pad must be in the same managed region, within twelve horizontal blocks between registered origins, and visibly identified by the station's preview. The twelve-block limit is a proposed local-service allowance to keep the first yard understandable, not a measured engine limit. No remote chunk or absent factory is activated by that link. The controlled assembly operation requires authorized access to both installation records. A clear work corridor may be authored as scaffolding or marked work space without pretending that a robot physically walks it before such an animation exists. Inputs are a negative-X parts tray at (−1.5, 0.75, 0), a rear power inlet at (0, 0.5, −1.5), a rear control endpoint at (0.5, 0.75, −1.5), and the front terminal at (0, 1.25, 1.5). The assembly handoff is a logical berth reference with visible route indication rather than an item pipe carrying an occupied vehicle. A blocked berth pauses before the next committed construction stage. A finished but uncommissioned craft remains there as that one craft. Acceptance covers blocked space, full stock, two contributors, cancellation, refit and reload at every stage, with no duplicated vehicle or lost committed parts. ## T1-SPEC-10 — Fuel Refinery and Fuel Pipe T1-M03 is the **Fuel Refinery**, the same function as IND-M45, not a second compulsory propellant processor. Its proposed two-by-two footprint and two-block height allow the compact dark housing, vertical orange treatment and top fittings in REF15 to remain readable. A front access strip of one block is required. The negative-X feedstock inlet sits at (−1, 0.75, 0), the positive-X SUPPLY01 outlet at (1, 0.75, 0), the rear power inlet at (0, 0.5, −1), and a top service hatch at (0, 2, 0). Opening the service hatch reserves an additional half-block above; normal routine use remains from the front. The refinery's first recipe must specify Earth-accessible inputs, produced propellant and treatment of every required secondary output. No chemical formula, electricity unit or batch yield is claimed confirmed by the artwork. The machine shows its actual process housing, fill state and selected destination. A restrained pump movement and pulse at a connected outlet communicate activity. An invalid tank or full destination stops transfer before losing material. Servicing never creates an uncontrolled launch-yard explosion as the default response to a routine stoppage. T1-M04 is the **Fuel Pipe**, not a universal invisible resource cable. A segment occupies a one-by-one-by-one placement cell with a proposed quarter-block central body and larger orange collars. Its initial straight orientation runs along X, with end centres (−0.5, 0.5, 0) and (0.5, 0.5, 0). Supported elbows and three-way junctions reuse the same centre and one or more face endpoints. A valve is a variant with an explicit handle sweep. These variants share the Fuel Pipe identity unless later manufacturing balance justifies a separate functional item. Two terminal-adapter variants resolve the difference between centred block-grid pipes and offset machine sockets. At the refinery, the host endpoint is refinery-local (1, 0.75, 0), while the outward grid endpoint is (2, 0.5, 0.5); its reserved space is X 1–2, Y 0–1, Z −1–1. A following straight segment has origin (2.5, 0, 0.5), so its negative-X endpoint meets that adapter exactly. At the pad, the host endpoint is pad-local (3.5, 0.25, 0), the grid endpoint is (4.5, 0.5, 0), and the following segment origin is (5, 0, 0); the adapter occupies X 3.5–4.5, Y 0–1, Z −0.5–0.5. These are compact stepped terminal fittings within the Fuel Pipe family, with their whole reserved volume previewed. Both endpoint normals oppose their mating faces, and all offsets rotate with the host. They introduce no new machine or compulsory processing step. Only SUPPLY01 uses this connection family. Every enabled segment belongs to one declared local transfer route with a source, destination and stop target. The initial plan records supply in source and destination containers, not as hidden fluid stock inside every decorative pipe section. Breaking a segment stops the next transfer commit; it does not spill, duplicate or refund an invented pipe volume. Non-owner stock is never discovered and drained merely because a route touches it. Fuel and breathing connections reject one another before operation, using different collar symbols and mechanical connector shapes as well as labels. ## T1-SPEC-11 — Oxygen Generator and grouped service functions T1-M05 is the **Oxygen Generator**, the same compact preparation role as IND-M40. The proposed first model is a one-block cube with the vented gray housing and blue screen from REF15. Its front interaction centre is (0, 0.65, 0.5). A compatible process input or atmosphere-service face is at (−0.5, 0.5, 0), breathing output at (0.5, 0.5, 0), and power inlet at (0, 0.25, −0.5). The chosen recipe determines what the input actually accepts. Its port label must change with a supported recipe rather than imply that airless lunar terrain supplies Earth atmosphere. The first working recipe should be decided through the Earth workshop balance pass and written once for the machine, recipe records and mission interface. Either a supported water-processing route or an Earth atmosphere route can satisfy the existing direction. Neither is assumed available on the Moon without its actual inputs. Tank filling is a transfer from real stored SUPPLY02, and the status panel distinguishes manufacturing new supply from moving an existing reserve. The shell may show a small fan or pump, but continuous motion must stop when its managed process is parked. T1-S01, **Refill, dust service and field charging**, groups existing life-support and workshop functions. Its recommended first world presentation is a one-by-two service rack, maximum two blocks high, or the same service frontage integrated into the shelter. It is not an obligatory fourth kind of supply processor. A front tank docking point, a separate field-cell slot and a small work/brush area make its tasks visible. Connections identify breathing storage, available electrical supply, repair stock and outgoing equipment independently. Refilling protects occupied-cabin and refuge reserves. Field charging uses EQ19 and SUPPLY03; cleaning and repairs consume only their specified stock. A service animation brushes a joint, secures a valve or seats a cell while the interface states the actual action. It does not imply that a cosmetic wipe restored an empty oxygen tank. On interruption, the equipment remains owned by either the player's inventory or the rack, never both. Acceptance includes disconnecting a refill, stopping power while charging, withdrawing unreserved stock and showing exactly which unavailable resource prevents the next useful action. ## T1-SPEC-12 — Launch Pad, Control Console and Storage Crate T1-M06 is the **Launch Pad**. Its foundation, deck, hazard boundary, small corner indicators, retracting proposed couplers and registered berth are separate parts of one installation. Fuel input is on its positive-X edge, breathing input on negative X, and power/control connections on the rear. Fixed external pipe routes terminate at the pad edge. The pad's managed couplers make the final connection to the parked rocket and retract before the craft moves. This avoids requiring the player to break a length of fixed pipe inside the departure column on every launch. The underlying stock remains with the real reservoir or vehicle throughout connection changes. T1-M07 is the **Control Console**, a two-by-one footprint and one-and-a-half-block maximum height in this proposal. Its wide screen and shallow worktop follow REF15. The rear control endpoint is (0.5, 0.5, −0.5), power is (−0.5, 0.5, −0.5), the front interaction centre is (0, 1, 0.5), and the Launch Key socket is (0.5, 0.9, 0.5). A one-block clear front strip supports operation. The console links to one declared pad or craft at a time; a visible name and outline prevent the player from preparing one vehicle and unintentionally launching another. Console pages begin with the selected mission and the next blocking action. Show actual crew, cabin state, destination, cargo, operating supply, protected return allocation and service requirements. Detailed balances remain available underneath. Departure can only be requested by an authorized operator, with the actual pilot seated and all required conditions satisfied. The key interaction starts a cancellable local sequence rather than bypassing checks. A changed load, obstruction or disconnected service recalculates readiness before commitment. Pure cosmetic cargo does not appear with the same urgency as missing breathing supply. T1-M08 is the **Storage Crate**, a one-block cube with gray panels and orange corners. The proposed top lid requires a half-block clear sweep above; a front interaction point identifies its contents and reservations. Authorised item transfer may use the rear face. Mounted cargo is a variant of this same role with a fixed access panel and no lid sweep into the cabin. The crate stores actual goods; mission allocation marks quantities in that inventory. First-lunar essentials must fit the configured safe manifest. The example six slots cannot overrule the complete shelter, breathing, field power and return requirements. ## T1-SPEC-13 — Structural parts, engine, tank, chip and key T1-I01 remains **Rocket Part and structural component family**. Its inventory presentation follows REF15's pale rectangular piece, dark openings and orange detail. Proposed display bounds are one block wide, half a block high and a quarter block deep. The inventory piece is not itself a full structural hull module. The assembly record maps consumed component quantities to authored body, nose, fin, cockpit-fitting and service-support stages. Those stage meshes are explicit installation variants with their own bounds. Keeping that mapping visible prevents every decorative plate from acquiring a separate mandatory inventory type. T1-I02 remains **Rocket Engine / Engine Module**. A one-block display or workshop component represents one managed cluster; the installed authored underside contains four nozzles within the Explorer's lower body. The mounting plane, propellant socket and inspection cover are explicit. The initial engine has one readiness/condition record, with four visual plume origins. A missing nozzle mesh is an asset defect, not a silently simulated failed fourth engine. Engine removal is a controlled service order in a safe grounded state, preserving the vessel's supply and vehicle identity. T1-I03 is **Fuel Tank**. Its proposed portable representation is half a block wide/deep and one block tall, with an unmistakable SUPPLY01 connector. Installed tanks use authored housings and attachment transforms; quantities, capacity and return assignments belong to the installed tank record. A filled portable vessel cannot be represented as both cargo and installed supply after a move. A reference orange band establishes the visual family, while a distinct fuel symbol and connector prevent confusion with an Oxygen Tank. Exact capacity waits for the complete mission and cargo budget. T1-I04 is **Navigation Chip / Guidance Chip**. The proposed half-by-half plate is one eighth of a block thick, with orange contacts and a blue centre as in REF15. It slots into the supported navigation/service position; it is reusable hardware, not a consumable route ticket. Route knowledge is associated with recoverable survey records. T1-I05 is the **Launch Key**, a small orange-headed object with an explicit key interface. Its proposed half-by-quarter-by-one-eighth display envelope is orientation-specific, not a physical keyhole dimension. It requests an authorized action; a lost key is replaceable through ownership recovery. Both items use distinct inserted and held transforms and never clone themselves through a control animation. ## T1-SPEC-14 — Suit, helmet and breathing tank T1-E01, **Tier 1 Player Space Suit**, implements EQ23 through the confirmed Minecraft-proportioned white/gray panels, orange bands, dark gloves and boots, navy visor and square backpack. T1-E02 is the **Space Helmet**, a component of that same outfit. T1-E03 is the **Oxygen Tank**, the portable breathing vessel under EQ24 containing SUPPLY02. Their meshes should be tested together with the actual player model. This specification recommends retaining normal player movement and collision dimensions, while keeping the visual backpack and helmet within the tested access envelope. The source art does not establish a larger player hitbox. A neutral-pose art envelope of approximately one block across/deep and two blocks high is a provisional review guide for the complete suited player. Arm extension, crouching, climbing, swimming, tool use and seated poses require separate swept checks. Helmet display bounds are proposed at 0.75 cubed; a carried Oxygen Tank is half a block across/deep and one tall. These display bounds do not replace the player's head or torso anchors. The helmet rotates with the head; the pack follows the torso; the tank attaches at a defined pack mount. First-person arms keep the same design language without forcing the full third-person pack into the camera. The recommended arrangement retains the integrated square backpack, with one removable tank socket built into its service side rather than adding a huge unreferenced cylinder silhouette. A breathing connector uses a capped, clearly labelled round fitting; the propellant family uses a different keyed collar. The suit's pack, helmet seal and tank state are checked as one understandable protection system. The helmet alone cannot make an incomplete suit ready. A missing tank is a hardware problem; an empty tank is a supply problem; the interface distinguishes both. The visor remains opaque navy from outside. In first person, a restrained optional visor edge and contextual suit information preserve the useful view. Do not apply a permanently dark full-screen blue mask, peripheral blind zone or heavy breathing animation as the default. Show breathing reserve, equipment charge and protection/service status with text or icons as well as colour. Warning sounds need independent control. Equip, tank-swap and cleaning animations cannot hide or delay a necessary retreat; their underlying transfers commit once and can resume safely when interrupted. ## T1-SPEC-15 — Starter refuge and recovery boundaries T1-S02 is **Starter lunar refuge**, delivered through EQ25 and the Lunar Shelter Controller. The proposed first structure reserves seven by nine blocks, maximum four blocks high, with its main entrance on +Z. A nine-by-eleven prepared terrain allowance surrounds the footprint. A separate three-wide, three-deep clear approach begins at the front edge and must remain usable. The footprint is a production proposal informed by REF03's compact white/orange habitat, warm entrance, utilities and storage; REF03 does not supply a measured floor plan. The intended first interior separates a small entry airlock from a protected sleeping/service cell. An initial fit layout reserves the front two blocks of interior depth for the airlock and the remaining rear volume for a bed, circulation, storage and a compact service face. The floor, two closures, usable standing heights and service volumes must be represented in the structure plan. The first supported operational stage is the complete airlock and sleeping cell with actual stored breathing and power. Decorative dish, mast, exterior crates and a larger workshop may follow. The controller must not mark a partly built shell breathable merely because the decorative final model was placed. The first lunar loadout carries the full starter materials and commissioning supplies from Earth. The functioning Explorer remains a retreat during construction. A suitable arrival offers feasible support and approach space without dictating exactly where every free-built addition must stand. The refuge is commissioned before the first committed underground descent. Later Moon inputs can improve or extend its services after their complete supply chain exists; they are never the ingredient that makes the first shelter work. T1-S03 is **Expedition Recovery Beacon mode** of EQ26 Communications beacon, with a proposed one-by-one base and two-block mast envelope for its field presentation. It reuses the existing device identity and does not demand a second beacon recipe. Recovery associates a participant, craft, supported refuge and return service through explicit records. A beacon shows its recognized destination, current availability and consequence before activation. Its pulse and mast animation communicate a real request. Recovery preserves progression and makes cargo consequences visible; it cannot refill arbitrary fuel, conjure an extra Explorer or become the intended way to complete an otherwise impossible first mission. ## T1-SPEC-16 — Typed ports and interface mapping The register records every proposed physical port and important interaction anchor. The following table gives the common site map in local XYZ coordinates. Pads and vehicles use separate origins; the Explorer transform is (0, 0.5, 0) relative to its pad. Port coordinates must be transformed before checking coincidence. The two fuel coupler endpoints therefore meet at pad (1.5, 2.5, −0.5), not at the rocket's untranslated coordinate. Breathing endpoints follow the same rule on negative X. | Host | Interface and direction | Local centre XYZ | Outward normal or interface type | | --- | --- | --- | --- | | Explorer | Fuel input, SUPPLY01 | 1.5, 2, −0.5 | +X; fuel-only keyed connector | | Explorer | Breathing input, SUPPLY02 | −1.5, 2, −0.5 | −X; breathing-only connector | | Explorer | Service power input | 0.5, 2, −1.5 | −Z; electrical connector | | Explorer | Mission/service data | −0.5, 2, −1.5 | −Z; control connection | | Launch Pad | External fuel input | 3.5, 0.25, 0 | +X; fuel-only | | Launch Pad | External breathing input | −3.5, 0.25, 0 | −X; breathing-only | | Launch Pad | External power input | 0.5, 0.25, −3.5 | −Z; electrical | | Launch Pad | External control connection | −0.5, 0.25, −3.5 | −Z; mission/service data | | Launch Pad | Extended fuel coupler output | 1.5, 2.5, −0.5 | −X; faces Explorer fuel input | | Launch Pad | Extended breathing coupler output | −1.5, 2.5, −0.5 | +X; faces Explorer breathing input | | Launch Pad | Extended power coupler output | 0.5, 2.5, −1.5 | +Z; faces Explorer power input | | Launch Pad | Extended control coupler | −0.5, 2.5, −1.5 | +Z; faces Explorer data input | | Fuel Refinery | Process feedstock / fuel output | −1, 0.75, 0 / 1, 0.75, 0 | −X / +X; different semantic types | | Oxygen Generator | Process input / breathing output | −0.5, 0.5, 0 / 0.5, 0.5, 0 | −X / +X; recipe-dependent input, SUPPLY02 output | | Service rack | Breathing input / equipment refill | −0.5, 0.75, 0 / 0, 1, 1 | −X / +Z; controlled refill | | Starter refuge | Breathing / power service input | −3.5, 1, −2 / 3.5, 1, −2 | −X / +X; explicitly typed | A process-feedstock input accepts only the recipe's approved input type. A power port carries the future project's chosen energy abstraction, not oxygen or a universal supply number. Control connections carry orders and status; they do not create inventories or transfer stock. Mechanical installation sockets accept the specified component family. Human interaction anchors identify an action surface and are never silently treated as machine transfer ports. All transfers name their owner, source, destination, requested amount, permitted reserve access and completion condition. The first network is local and bounded. Managed regional eligibility governs active work, including connected machinery; a control link does not wake remote production. Adjacent crates or machines become eligible only through a declared permission and configuration. Fuel, breathing and power remain different services even if one pad houses all three. Colour assists recognition, while distinct symbols, connector shapes and plain labels carry the actual distinction. ## T1-SPEC-17 — States, animations and accessible feedback State is composed from an operation state, a blocking reason and a service condition. For example, a refinery can be waiting because its output tank is full while also due for optional cleaning. A single overloaded colour should not try to encode that whole situation. The primary player message states the action needed now, with details available separately. Machine motion is a consequence of the recorded state; it is not the source of progress. | Asset family | Required visible states | Initial animation treatment | | --- | --- | --- | | Fabrication and assembly | Unpowered, idle, missing stock, ready, active, output/space blocked, paused, service required, complete | Small tool/clamp motion, visible component stages, terminal progress and restrained active light. | | Fuel and breathing supply | Idle, producing, transferring, missing input, incompatible connection, destination full, paused, service required | Pump/fan movement, connector indication, actual reservoir gauge; no constant active effect while paused. | | Pad and Explorer | Vacant or unassembled, assembling, parked, servicing, boarding, ready, countdown, departing, passage, approach, landed, recovery required | Connection pose, closures, short cancellable departure cue, four-source plume, stable arrival and service states. | | Suit and portable equipment | Unfitted, equipped, supplied, low reserve, empty, service required, charging/refilling, ready | Small attachment actions and clear status; urgent information remains visible during movement. | | Refuge and beacon | Unbuilt, building, incomplete service, commissioned, occupied, parked, blocked recovery, recovery active | Authored construction stages, closure indicators, utility cues and restrained beacon pulse. | Animation priority is deliberate. First priority is physical clearance and readable blocking feedback; second is closures, connectors and attachment actions; third is meaningful work and assembly motion; fourth is launch/landing presentation; fifth is cosmetic wear and ambient detail. Cosmetic activity never blocks a necessary interaction or prevents a saved state from loading correctly. A paused regional process has an intentionally settled pose, while ordinary global Minecraft behaviour remains governed by its own systems. Airlock and supply warnings use shape, wording and optional sound. Screen flicker, rapid flashes, heavy camera shake and prolonged forced camera motion are unnecessary for the first release. Reduced-motion and reduced-effects settings should retain launch timing, cancellation, mission status and arrival feedback. A low-supply warning must remain readable over a plume or dark visor. The cabin's visual light can communicate occupancy, but the breathable-state label is derived from actual closures and service records rather than the presence of a lamp. ## T1-SPEC-18 — Ownership, transfers and regional persistence The proposed ownership model distinguishes an owner, authorized operators, contributors and viewers. Owners manage configuration and reserve policy; operators perform permitted services and mission actions; contributors deposit accepted materials; viewers inspect public progress. These are functional permissions to reconcile with any existing settlement system during the code audit, not a demand to invent a second account framework. A Launch Key proves a requested control interaction and never overrides these permissions. A transfer or construction order reserves real stock before work and commits its result once. Its record includes origin, destination, quantity, owner, stage and operation identity. Materials reserved for a mission stay visibly present in their container or installed vessel until transferred. Return fuel, breathing contingency and occupied-refuge service allocations cannot be used by ordinary automation. Revising those allocations is a mission change with the consequence shown before commitment. No invisible duplicate inventory is maintained simply to make the console's manifest look complete. The Explorer has one authoritative location state: an assembly berth, a parked site, a recognized travel stage, a landed site or a supported recovery state. Passengers are recorded against actual supported seats. The first configuration recommends one pilot; additional multiplayer participants use independently prepared craft until extra seating and its supply/cargo implications are deliberately designed. A passenger cannot travel as an item or appear at a destination without a recorded seat. A reload or disconnect during passage restores the same operation and never leaves both a landed and travelling copy. Authored production, construction, service consumption and events follow the existing eligible-participant regional rules across horizontal bounds, depth and dimension. Inactive managed regions retain their exact saved state without a catch-up consumption penalty. An occupied lunar refuge remains active for its participants when the owner returns to Earth. Dispatch of already reserved goods may progress through the existing receiving-region freight rule, but that cannot start new remote refinery output. Recovery and failed placement must leave a coherent inventory, craft and participant state with an explained next action. These conservation and absence rules are completion requirements, not optional polish. ## T1-SPEC-19 — Prioritised implementation backlog and dependencies The following tasks are a proposed future BUILD backlog. All are unstarted in the available material. T1-BLD01 is a pre-BUILD inspection dependency; the remaining tasks require the user's explicit BUILD approval for their selected scope. The register carries asset mappings, dependencies, outputs and acceptance detail so later reports can update individual tasks without silently claiming that concept artwork is implemented content. | Task | Priority and dependency | Observable completion | | --- | --- | --- | | T1-BLD01 — Inspect the actual mod project | P0; project access | Record loader/version, structure, existing rendering, world generation, saving and networking paths. Identify reusable systems and unresolved limits without claiming missing code was tested. | | T1-BLD02 — Measure Explorer and player fit | P0; BLD01, T1-DEC01 review before final art | A measured mock-up proves or rejects the candidate hull, airlock, pilot position, tank spaces, boarding and exit. Record every changed dimension. | | T1-BLD03 — Freeze coordinates and interface contract | P0; BLD02 | All rotations, world transforms, anchors, bounds and coupler positions agree between previews, models and recorded interfaces. | | T1-BLD04 — Define identity, permissions and transaction records | P0; BLD01 | A documented state model covers unique craft location, real stock, operators, reservations, cancellation and recovery. | | T1-BLD05 — Implement first fabrication and assembly loop | P1; BLD03–04, T1-DEC02 review before final art | Produce real parts, erect authored stages in a valid berth, pause/resume and commission one Explorer without duplicate outputs. | | T1-BLD06 — Implement fuel, breathing and charging services | P1; BLD03–04 | Earth inputs produce declared supplies; incompatible ports reject; refill and charging conserve stock and protect reserves. | | T1-BLD07 — Implement pad, console and cargo preparation | P1; BLD03–06 | Name a craft, load the complete safe manifest, show blockers, retract services and authorize only a valid selected mission. | | T1-BLD08 — Implement suit, tank and service interactions | P1; BLD02, BLD04, BLD06 | Equip, fill, warn, swap, clean and charge with usable views, actual quantities and safe interrupted transfers. | | T1-BLD09 — Implement cabin and airlock operation | P1; BLD02–04, BLD08 | Board, close, isolate, cycle and exit using the physical layout; service loss and occupied states are readable. | | T1-BLD10 — Implement bounded travel and return handoff | P1; BLD07, BLD09 | Ground departure, passage, arrival and return preserve one craft, supported crew, cargo and allocations through interruption. | | T1-BLD11 — Implement first lunar arrival and refuge | P1; BLD08–10, lunar placement audit | A valid site supports the carried shelter; commission the sleeping cell before descent; retain independent cabin retreat. | | T1-BLD12 — Implement recovery and changed-arrival handling | P1; BLD04, BLD10–11 | Lost key, interrupted mission, blocked pad and supported distress cases offer a recoverable next action without free supply or duplicated craft. | | T1-BLD13 — Produce final Tier 1 models and textures | P2; BLD02–03, both creative reviews | Every asset matches approved appearance, tested bounds, named parts and typed interfaces; editable sources are retained. | | T1-BLD14 — Add operating animations and feedback | P2; BLD05–13 | State-driven closures, work motion, service coupling and launch effects remain correct with reduced motion/effects. | | T1-BLD15 — Exercise one complete Earth–Moon–Earth expedition | P0 verification gate; BLD05–12 | An Earth-only preparation fits the actual cargo, reaches a working refuge and first descent, returns samples and enables a useful home improvement. | | T1-BLD16 — Verify persistence, shared use and measured performance | P0 verification gate; BLD14–15 | Focused interruption, contention and regional tests conserve the same stock and craft; performance is measured on a declared setup. | T1-BLD05 includes the minimal registered pad foundation and empty berth needed to erect the craft; T1-BLD07 adds its complete service, console, cargo and mission-readiness behaviour. This division avoids a circular dependency between assembling the first vehicle and implementing its launch installation. The dependency sequence should not force final textures before a usable gray-box voyage exists. Conversely, a functioning debug launch is not completion of the full Tier 1 experience. A build report should distinguish functional prototype, art-integrated content, tested mission and release-ready presentation. T1-BLD15 can establish the functional voyage with temporary assets. T1-BLD16 follows both that voyage and T1-BLD14, so final models, hatch and connector animations, collision, accessibility and measured performance receive an integrated check before closure. Broader Moon content, enhanced refinery throughput, multiple seats and later spacecraft follow separate approved scope rather than expanding these tasks implicitly. ## T1-SPEC-20 — Acceptance scenes, pending artwork and handoff The production handoff requires three kinds of evidence. A fit scene shows the Explorer, suited player, pad and station arrangement at measured scale. A working yard scene demonstrates the connected manufacturing and preparation loop. A complete expedition scene demonstrates that those objects support the promised lunar experience. These are future in-game checks and model-review outputs; no such implementation is claimed completed by this planning slice. Fit acceptance includes walking between fins, climbing the boarding steps, opening and passing the outer hatch, cycling the two boundaries, climbing to the cockpit, sitting, looking through the actual window, reaching cargo and services, and exiting again with the complete suit. Repeat the geometry checks at all four supported facings. A highlighted blocked approach must correspond to an actual blocked volume. An object outside the declared clearance should not prevent launch merely because its decorative mesh is nearby. System acceptance includes a full output tray, missing fuel input, incompatible breathing connection, interrupted refill, changed mission cargo, a second contributor, loss of power, save/reload during assembly, a parked region and an occupied refuge after the owner leaves. The complete first-lunar manifest must include its working cabin, EQ25 starter shelter, actual supplies and reserves; orbital rehearsal uses its own smaller valid manifest. Return to an obstructed Earth pad must preserve a supported alternative. A successful mission produces a useful discovery or material application already described in the direction. No additional images are generated in this slice. The next small generation plan remains the Old Valley opening board and the early workshop/construction-state board managed by the First Playable plan. Tier 1 uses the confirmed reference library first. Its pending production visuals are a measured rocket/cabin cutaway, consistent station dimensions, socket close-ups, a service-coupler motion sheet, suit/tank attachments and shelter stages. Those are specific future model or diagram tasks; generation should only be requested if a remaining visual question cannot be resolved from the supplied art and measured layouts. The immediate review queue is T1-DEC01 for rocket scale and T1-DEC02 for the manufacturing-station distinction. All other dimensions and conventions remain labelled proposed defaults pending fit and implementation evidence. The document retains the full earlier direction and every supplied image. Tier 2 and Tier 3 stay at their provided overview level, with no new detailed systems or generated artwork. The next decision after this planning work is an explicitly scoped BUILD instruction, supported by an actual project inspection and a finite implementation target.