**Status: an independent worked proposal for review.** This develops two open questions in [Connecting The Station](/Hold%20The%20Flood/Connecting%20The%20Station): whether several converter placements can produce complete stations, and whether obtaining the required adjacencies becomes repeated death cycling. The example provides explicit sockets, two non-overlapping final layouts, a locally legal dead end and its recovery. It also proposes one controlled meeting at the next shift. These are paper constructions, not a simulation, playtest or selected game rule.

A collection of individually compatible seams does not necessarily leave room to attach every remaining region. The decisive resource in this example is an **unoccupied physical face**, not a scarce power source.

The current [Owner Brief](/Hold%20The%20Flood/Brief) selects persistent room-group connections and a late whole-station puzzle. [Shifting Station Options](/Hold%20The%20Flood/Shifting%20Station%20Options) records that selection; its earlier recommendation is historical, not a reversal of the owner's choice. The exact mechanism and final layout behaviour remain open.

This candidate follows Connecting The Station's rigid groups, reversible latches and separation of walking connections from diagnostic signals. It therefore assumes that full connection stabilises the layout. If continued rearrangement within a fully joined station is selected instead, this construction needs redesign.

Each region occupies one square cell for this small spatial example. East increases x; north increases y. Regions retain orientation, and a joined group translates without changing its internal arrangement. Real rooms need not be square, but their collision and threshold rules cannot be omitted from a full specification.

BL, AM and RD identify three service families. They also have distinct non-colour marks: double bar, single ring and triple chevron. “In” and “out” describe the latch's service handshake, **not a one-way walking door**. Once latched, people can walk either way.

| ID and illustrative region | Persistent-latch sockets | Role in this example |

|---|---|---|

| S — Ship collar | East: BL-out | Root of the walkable network |

| F — Foundry junction | West: BL-in; East and North: BL-out | Two branches from the ship |

| D — Decontamination | West and South: BL-in; East: AM-out | BL-to-AM converter |

| I — Imaging exchange | West: AM-in; East: RD-out | AM-to-RD converter |

| G — Bypass hall | West and South: BL-in; East: RD-out | Direct BL-to-RD converter |

| X — Pump annex | West: RD-in; East: RD-out | Ordinary RD-through region that must also be included |

| A — Archive | West: RD-in | Terminal region |

| W — Observation ward | West: RD-in | Another terminal region; no rescue state is implied |

Each socket accepts one physical neighbour. An out socket latches to an adjacent, facing in socket of the same family. These are the only persistent-latch sockets in this example. Temporary exploration doors are a separate layout concern.

A reusable source activates each attempt locally. It can be recovered and reused without undoing an existing latch. The example has no global power budget and makes no claim that maintaining a diagnostic signal is necessary for completion. Its converters have fixed mappings; optional switchable modes are deliberately outside this demonstration.

Before this late construction task, the player has discovered all eight regions and inspected the relevant faces. That assumption isolates assembly from the separate problem of finding unknown rooms.

Coordinates below describe final physical arrangements, not a map the interface hands to the player.

| Region | Layout 1: balanced branches | Layout 2: shorter Archive branch |

|---|---|---|

| S | (0, 0) | (0, 0) |

| F | (1, 0) | (1, 0) |

| D | (2, 0) | (1, 1) |

| I | (3, 0) | (2, 1) |

| G | (1, 1) | (2, 0) |

| X | (2, 1) | (3, 1) |

| A | (4, 0) | (3, 0) |

| W | (3, 1) | (4, 1) |

| Join | Facing sockets | What the growing network gains |

|---|---|---|

| S–F | S East BL-out / F West BL-in | Foundry |

| F–D | F East BL-out / D West BL-in | First converter |

| D–I | D East AM-out / I West AM-in | Two-step access to RD |

| I–A | I East RD-out / A West RD-in | Archive |

| F–G | F North BL-out / G South BL-in | Direct converter on the other branch |

| G–X | G East RD-out / X West RD-in | Pump annex before the terminal |

| X–W | X East RD-out / W West RD-in | Ward |

From the ship, Archive is four latch crossings away. Ward is also four: S–F–G–X–W.

| Join | Facing sockets | What changes |

|---|---|---|

| S–F | S East BL-out / F West BL-in | Same root |

| F–G | F East BL-out / G West BL-in | Direct converter goes toward Archive |

| G–A | G East RD-out / A West RD-in | Archive reached in three crossings |

| F–D | F North BL-out / D South BL-in | Two-step converter chain moves to the other branch |

| D–I | D East AM-out / I West AM-in | AM changes to RD |

| I–X | I East RD-out / X West RD-in | Pump annex stays inside the chain |

| X–W | X East RD-out / W West RD-in | Ward reached in five crossings |

Both layouts contain all eight regions with seven persistent joins. Every listed pair occupies neighbouring cells with complementary facing sockets; no cells overlap. Following the two branches from S reaches every region in each layout.

This establishes **two feasible final arrangements for these specified pieces**. It does not establish that every shuffle offers their next step, that these are the only solutions, or that the complete game's geometry is solvable.

The choice has an intelligible consequence: Layout 1 gives a four/four split; Layout 2 gives a three/five split. If Archive is the player's frequent destination, the second may be attractive. If Ward matters equally, the first may be preferable. Crossing counts alone do not establish travel time, oxygen cost or safety; encounters and real room dimensions could change the preference.

Build Layout 1's S–F–D–I–A branch and F–G. Then put W at (2, 1) and join **G East RD-out to W West RD-in**, omitting X.

All six completed seams are legal. Seven regions form one ship-rooted network. X is the only missing region.

Yet X cannot attach anywhere:

- The network's two RD outputs, at I and G, are occupied by A and W.

- The network's two RD inputs, at A and W, are likewise occupied.

- X's RD input and output cannot connect to the remaining exposed BL or AM faces.

More charge, cycling converter diagnostics or repeatedly reshuffling X cannot free an occupied socket. This is a concrete counterexample to “keep making valid joins and eventually everything will fit.” A local preview was correct to permit G–W; it should not pretend it evaluated the whole construction.

1. Walk S–F–G and operate the release control on G's side of G–W.

2. Release **only G–W**. The five other latches persist. W remains physically adjacent this life but is no longer bound to the root.

3. Obtain G East beside X West, then latch G–X.

4. Obtain X East beside W West, then latch X–W.

The final arrangement is Layout 1. The player repairs one mistaken seam without dismantling either converter chain or paying for replacement parts.

Both sides of each seam need accessible release controls. In this specific mistake, G's control is reachable from the ship through two completed joins before anything is released. That is an actual access path, not an assurance that an unspecified lever exists somewhere.

The physical replacement needs W to vacate its former cell; it cannot be completed merely by changing a signal. The next section addresses how the player obtains that new arrangement.

After discovering a late service controller, the player may register **one selected pair of previously inspected faces** to meet at the next death-triggered shift. One face must be on the ship-rooted group; the other belongs to a different, discovered group.

This is an additional proposed capability. It does not follow automatically from knowing the socket families.

The controller validates the chosen pair only. It does not search the journal, identify a missing converter, recommend which room to use or select a solution. Validating compatibility is the same bounded kind of report contemplated in [Player Information](/Hold%20The%20Flood/Player%20Information).

An accepted request means all of the following:

- The named sockets are unoccupied, compatible and on different rigid groups.

- A physically valid next arrangement exists with those exact faces opposed.

- Every other persistent join, room identity and committed object state is preserved.

- The selected root-side threshold is reachable through the existing walkable network.

- The **next death-triggered shift** creates that adjacency. “Increased chance,” “eventually” and “next eligible shift” are not equivalent promises.

- The player must still travel to the threshold and perform the latch action. The controller creates no persistent join and grants no automatic completion.

Other unbound parts of the station can still change neighbours. The request discloses no names or locations for undiscovered rooms, and the rest of the new arrangement remains unknown.

| Event | Required behaviour |

|---|---|

| Player selects an uninspected face or unknown region | Refuse registration; do not reveal its family, identity or route |

| Faces mismatch or one is occupied | State that local reason; no charge or item is consumed |

| Two faces are already in one rigid group | Explain that shifting preserves their existing relative positions |

| Selected groups cannot fit together without overlap | Refuse acceptance; do not secretly sever a different join |

| A legal arrangement is established | Display the two selected endpoints and “Reserved for next shift”; do not display a solved station map |

| Player later changes a requested endpoint or group so the promise becomes invalid | The action preview identifies cancellation of the reservation; commitment clears it visibly |

| Player cancels or replaces the request | Clear or replace the one request without a new resource tax |

| Player returns alive | Retain the request; do not trigger a shift |

| Player dies, naturally or deliberately, with the request still valid | Fulfil the promised adjacency once; consume the request, not an inventory item |

| Journal is open | Allow notes about an intended pair, but no world-time registration or latch action completes |

The controller's feasibility check is a **content and technical-design obligation**, not an implemented solver. For arbitrary rigid room shapes, matching service labels is insufficient to promise collision-free placement. The eight-cell layouts above provide concrete witnesses for their own requests; the full content set needs authored admissible arrangements or another separately specified method that can substantiate each acceptance.

A refusal may say that the selected groups lack clearance. It must not expose unseen room outlines as an explanation. The proposal does not claim every desired pair can fit or that a refusal alone teaches the correct alternative.

After releasing G–W, reserve G East / X West. At the next shift, X occupies the freed (2, 1) position while W is unbound elsewhere. Latch G–X.

If W is already beside X, latch it immediately. Otherwise reserve X East / W West. The following shift can place W at (3, 1); latch X–W. Both final placements avoid the root's existing cells.

Thus this particular repair costs **one release, two new joins and at most two requested shifts**, provided the player completes each offered join and does not invalidate a reservation. Oxygen and travel remain ordinary costs. There is no random retry count and no need to break S–F, F–D, D–I, I–A or F–G.

If new adjacencies arise only at death, the required pair is absent, and all other useful current work is finished, obtaining that pair still requires another death. A deterministic appointment cannot remove that dependency. The owner already permits carried-property return, and deliberate death must not acquire a special confiscation penalty to conceal it.

The request removes **uncertain repeated deaths for the same pair**, not death as a possible assembly tool. Players can queue a useful meeting, pursue another expedition and let the next natural death deliver it. At the very end, they may choose deliberate death to obtain the final arrangement. That is the honest accepted cost.

For these eight already discovered, initially separate pieces, either listed construction order can grow from S in seven accepted meetings, with fewer requested shifts if some useful adjacencies already exist. This is a bound on this assembly sequence after discovery, not a campaign duration or a guarantee of seven enjoyable expeditions.

Scaling one-new-component-per-request to forty initially separate playable instances could still mean thirty-nine requested shifts. The [Whole Game Outline](/Hold%20The%20Flood/Whole%20Game%20Outline)'s SMALL band distinguishes forty placed instances from four regions and twenty-four reusable modules; those counts are not interchangeable. Existing groups and incidental extra joins can reduce requests, but content counts alone do not establish the actual cadence.

If even bounded deliberate death is unacceptable, the design needs a **living realignment action** or another way to change the relevant adjacency. That would be a larger new mechanic, not a wording fix to the shift rule.

A possible evidence sequence, still proposed:

1. Early local work demonstrates a reusable source: removing it leaves a completed latch intact.

2. Two observed service fixtures demonstrate BL-to-AM and AM-to-RD behaviour; a different hall demonstrates direct BL-to-RD behaviour.

3. A small optional branch shows that inserting a through-room before a terminal preserves a useful outward face.

4. The late controller reveals only its own ability to arrange a specified, registered meeting.

5. The player combines those observations to choose a branch layout and request the next useful pair.

A neutral roster can report all eight known regions and seven currently attached in the failed construction. It should not mark G–W “wrong,” identify X's correct insertion point or rank the two completed layouts.

The discovery is actionable: a familiar room can become an adapter or an intermediate piece in a larger construction. The player then chooses which destinations receive the shorter branch. The example demonstrates that choice exists; it does not establish a deep enough mystery for the whole game.

| Approach | Strongest case | Cost left visible |

|---|---|---|

| Uncontrolled shuffles only | Least additional machinery; every useful meeting remains a discovery | No finite wait bound for a particular required pair unless the distribution supplies one |

| One registered meeting next shift — proposed here | Player planning determines one next opportunity; preserves death-triggered rearrangement and manual joining | Adds registration and fit-validation rules; deliberate death can remain the fastest final step |

| Living local realignment | Player can finish a known construction without dying to move a room | Requires a new movement action, collision rules and potentially a broader change to the station's fiction and pacing |

**Recommended decision for review:** retain the two-layout example as a concrete design fixture, and consider one guaranteed registered meeting as a late-game capability. Do not describe it as eliminating all death cycling.

If accepted:

- **Connecting The Station:** add socket occupancy to its authored constraints and replace its unbounded adjacency wait with the selected request contract; preserve independent walking, latch and diagnostic states.

- **Shifting Station Options:** define which registered meeting the next shift must honour without changing existing rigid groups. Clearly label the old Option 2 recommendation as historical.

- **Player Information:** specify inspected-face identifiers, pending/cancelled/fulfilled request reports and local refusal reasons; no optimal-layout or hidden-room display.

- **Whole Game Outline:** count ordinary joins and requested shifts separately from special converter sites. A small number of special puzzles does not establish the burden of assembling every placed instance.

- **Authoring specification:** enumerate each placed instance's footprint, sockets, traversal and release access; record at least two complete constructions where intended; include a wrong-join recovery and a valid placement witness for every accepted request class.

Still outstanding are the complete station inventory, intermediate exploration routes, non-square group collisions, the late controller's discovery/access conditions and the owner's final-layout decision. This contribution supplies a bounded piece of that design work rather than declaring those remaining obligations solved.