# Wave-1 Railiance Home Reef Contract

## Purpose

Summarize the initial grouped home-reef contract `reef-railiance` owns in wave
1.

This repo starts from already-reviewed source documents rather than inventing a
new substrate model:

- `railiance-master/docs/reef-first-wave-rollout.md`
- `railiance-master/docs/reef-substrate-model.md`
- `railiance-infra/docs/reef-first-wave-source-map.md`

## What `reef-railiance` Owns

Wave 1 assigns these concerns to the reef:

- the grouped Railiance home-substrate identity
- current member and topology facts for that grouped reef
- the default hosted-rail statement for the home substrate
- future grouped `rapp` bindings for that substrate
- reef-local runbooks, overlays, and evidence when they become substrate-owned

## What Stays In `railiance-infra`

Wave 1 keeps these concerns in the canonical S1 ownership repo:

- server inventory authority
- OS provisioning and hardening logic
- SSH key and convergence mechanics
- source-backed server facts that are not yet reef-localized
- future split criteria that still depend on broader S1 review

## Published Substrate Assumptions

Wave 1 `reef-railiance` may assume:

- `Railiance01` is the first current member
- `rail-kubernetes` is the first primary rail stance
- additional Railiance home servers may join when they share the same grouped
  substrate boundary

Wave 1 `reef-railiance` must not assume:

- that every future Railiance server belongs here automatically
- that platform or workload ownership moves into this repo
- that grouped membership is permanent if lifecycle or security boundaries split

## Migration Constraint

Until the extraction is complete, `railiance-infra` remains the canonical S1
source of truth.

The active migration-window compatibility rules live in
`docs/retained-s1-handoff.md`.

`reef-railiance` should become the durable grouped substrate home first. Only
then should additional bindings, runbooks, and substrate-local overlays move
here in a migration-safe sequence.