Define derived rail and Qonto readiness architecture

docs/adr/ADR-0006-reef-production-admission.md

@@ -0,0 +1,29 @@
+# ADR-0006: Reef Production Admission
+
+Date: 2026-07-26
+Status: Accepted
+
+## Context
+
+Fabric topology can say that a reef hosts a rail or binds a workload, but that
+does not demonstrate capacity, isolation, recoverability, or approval for a
+critical internet-facing service.
+
+## Decision
+
+Rail and `rapp` bindings use explicit readiness states: `declared`,
+`installed`, `verified`, `production-approved`, and `deprecated`.
+
+Critical workloads require machine-readable conformance evidence plus explicit
+acceptance of residual risks that cannot be automated. Mixed-rail reefs use
+defined split triggers.
+
+The detailed contract is
+[`docs/reef-production-readiness-contract.md`](../reef-production-readiness-contract.md).
+
+## Consequences
+
+- `hosts_rail` and `binds_rapp` no longer imply deployability.
+- `reef-railiance` may host Knative in wave 2, but Qonto cannot be called
+  production-approved solely from that declaration.
+- Repeated evidence collection should become functional automation.