First-Wave reef Rollout

Context

Railiance now has a reef model, but it needs a concrete first rollout.

The current substrate reality is not uniform:

• Railiance01 is the clearest new-workload home
• CoulombCore is still active but transitional
• the workstation role is operator edge compute rather than server substrate

At the same time, S1 ownership is ambiguous because railiance-hosts and railiance-infra duplicate each other.

Decision

The first-wave reef rollout is:

1. reef-railiance
2. reef-coulombcore
3. reef-ops-workstations

railiance-infra is the canonical S1 ownership repo going forward.

railiance-hosts is treated as predecessor or duplicate state to be retired, frozen, or reduced later rather than as a second canonical S1 architecture home.

Consequences

Positive

• Railiance gets a grouped home-reef seed whose name remains stable as more home servers are added.
• Transitional CoulombCore reality is acknowledged without being treated as the long-term preferred production pattern.
• Operator edge compute is modeled without defaulting to one repo per machine.
• Reef planning now rests on one canonical S1 ownership line.

Required Follow-On Work

• Create repo-local rollout work for the first reef repos.
• Define how additional Railiance home servers join reef-railiance and what future split criteria would justify narrower reefs.
• Plan the railiance-hosts cleanup direction relative to railiance-infra.

Constraints

• Multi-rail reefs are acceptable early, especially on transitional substrates.
• Production-grade separation should still prefer clearer purpose and primary rail boundaries as criticality rises.
• Transitional substrate nicknames should remain provisional until the pattern is stable enough to canonize.

Notes

This ADR chooses the first rollout set. It does not require that every future substrate be modeled the same way.