Date: 2026-07-25 Status: Accepted

## 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.