Clarify cluster boundary for rail-kubernetes

docs/deployment-lifecycle.md

@@ -9,16 +9,24 @@ stage must leave evidence, every promotion must have a rollback path, and
 critical workloads require explicit human approval before production traffic is
 changed.
 
+Ownership note: this specification is temporarily hosted in
+`railiance-cluster` during the wave-1 split. Its long-term home is future
+`rail-kubernetes`; `railiance-cluster` should retain only substrate
+prerequisites and compatibility shims once that repo exists.
+
 ## Scope
 
-This specification is owned by `railiance-cluster` because it defines the
-cluster runtime contract for promotion gates, canary validation, production
-routing, and rollback expectations.
+This specification currently lives beside the cluster substrate because the
+compatibility tooling still lives here. Long-term ownership is not S2.
 
 Repo boundaries:
 
-- `railiance-cluster` owns the lifecycle semantics, cluster prerequisites,
-  ingress/routing expectations, and acceptance gates.
+- future `rail-kubernetes` owns lifecycle semantics, generic promotion gates,
+  canary validation, production routing expectations, rollback expectations,
+  and the generic workload contract.
+- `railiance-cluster` owns only the substrate prerequisites published to that
+  rail: cluster connectivity, namespace behavior, ingress availability, and
+  operator/runtime expectations.
 - `railiance-apps` owns workload-specific Helm values, application release
   definitions, and production workload configuration.
 - `railiance-platform` owns shared platform services such as databases,
@@ -329,4 +337,3 @@ bin/railiance rollback <overlay-dir> --plan             # rollback to previous s
 
 The exact command names may change as implementation lands, but the behavior
 must preserve the stage gates and evidence requirements in this document.
-