Finish first repo-family materialization wave

docs/reef-substrate-model.md

@@ -128,7 +128,7 @@ A reef name should follow the durable substrate identity used by operators.
 Good examples:
 
 - `reef-coulombcore`
-- `reef-railiance01`
+- `reef-railiance`
 - `reef-workstation`
 - `reef-ops-workstations`
 
@@ -176,18 +176,18 @@ kind of substrate. Terms such as "associate", "sidecar", or "comet" may be
 useful exploration language, but they should stay provisional until the pattern
 repeats and earns a stable place in the framework vocabulary.
 
-### `RAILIANCE01`
+### Railiance Home Substrate
 
-`reef-railiance01` is reasonable if Railiance01 is separately managed, migrated,
-or recovered, rather than being just another fungible node in a larger
-substrate.
+`reef-railiance` is reasonable when Railiance home servers are expected to
+share one durable operational substrate boundary, with `Railiance01` as the
+first current member rather than the permanent repo name anchor.
 
-At the current maturity level, it is acceptable for `reef-railiance01` to host
+At the current maturity level, it is acceptable for `reef-railiance` to host
 `rail-kubernetes` and later also `rail-knative` if that is the most pragmatic
-way to support early workloads.
+way to support early workloads across that grouped home substrate.
 
-If that substrate becomes production-critical or security-sensitive, reassess
-whether a clearer reef separation is warranted.
+If member servers later diverge enough in lifecycle, access path, or security
+boundary, reassess whether the grouped reef should split into narrower reefs.
 
 ### `WORKSTATION`