Define derived rail and Qonto readiness architecture

docs/repository-axes.md

@@ -31,6 +31,11 @@ For the current phase of Railiance:
 
 This means the repo model is intentionally ahead of the repo count.
 
+Rails may compose. `rail-kubernetes` is the default base rail, while
+Kubernetes-hosted execution specializations such as `rail-knative` are derived
+rails with an explicit, versioned base-rail dependency. A derived rail owns
+only the semantics it changes; it does not fork the common workload lifecycle.
+
 ## The Four Repo Families
 
 | Prefix | Axis | Unit | Primary question answered |
@@ -90,6 +95,10 @@ A rail owns the execution semantics for workloads on that architecture:
 
 A rail is not the workload itself and not the substrate it runs on.
 
+A rail declaration identifies whether it is a `base` or `derived` rail. A
+derived rail names its base contract, inherited semantics, overrides,
+compatibility constraints, and readiness state.
+
 In the current Railiance model, `rail-kubernetes` is the default base rail.
 Other rails should be introduced only when their runtime semantics justify a
 distinct lifecycle, contract, or operator model.
@@ -187,6 +196,10 @@ This separation reduces confusion between:
 - workload identity
 - deployment location
 
+Topology and readiness are also separate. A reef may declare that it hosts a
+rail or binds a `rapp` without that combination yet being installed, verified,
+or production-approved.
+
 ## Creation Rules
 
 Use the following default rules.