--- id: RMASTER-ADR-0006 title: "Reef Production Admission" status: accepted revision: "accepted-3" owner: railiance-master last_reviewed: "2026-09-21" review_interval: 6m --- # 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). Who may reach a listener is a different axis: [`ADR-0008`](ADR-0008-private-by-default-exposure.md). Production admission does not imply a public surface. A public surface requires this admission **and** an exposure grant. Neither admission nor exposure is an authorization decision. Whether an actor may perform an action on a resource is `access-engine` ([`ADR-0009`](ADR-0009-netkingdom-security-layer-interaction.md)). `production-approved` MUST NOT be read as permission to act. ## 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. - `production-approved` is not permission to publish a listener. See ADR-0008. - `production-approved` is not an authorization decision. See ADR-0009. ## Revision accepted-3 (2026-09-21): the change path The founder decided the Kubernetes change gate on 2026-09-21, exercising `GOVERN @ estate` (the-custodian `docs/kubernetes-change-gate-decision.md`). Terms follow SecurityCanon Mode of Authority v0.2.0, which is still a draft. The text above is left as accepted-2 recorded it. This section adds one consequence and does not change the Decision. **Added consequence: `production-approved` also fixes the change path.** | Readiness state of the target | Path for a change | `Activation` | |---|---|---| | `declared`, `installed`, `verified` | Direct `ADMINISTER @ realm:kubernetes` | `APPROVED`: founder approval of the construction plan | | `production-approved` | `CONSTRUCT @ `, reconciled by ArgoCD | `APPROVED` for the change; the merge is the gate | | `production-approved`, emergency | Direct `ADMINISTER @ realm:kubernetes` | `BREAK_GLASS`, recorded, then reconciled back into the manifest repository | The reason is the `EvidenceBoundary` dimension. A direct apply is `target-audited`: only the realm being changed holds the evidence. A change through the manifest repository adds `external-audited` evidence, which outlives both the actor and the realm. This is a statement about evidence, not about trust in any actor. **Still not an authorization decision.** The change path is a quality gate on a change. It does not say whether an actor may perform an action; that remains `access-engine`'s question (ADR-0009, Decision 5). `production-approved` still MUST NOT be read as permission to act, and it does not make any engine a party to the path. `BREAK_GLASS` is an activation value, not a mode and not a grant. **Tiering axis.** The tier follows readiness state, not the canon's `Environment` dimension. railiance01 is a single cluster, so every workload on it shares one `Environment`, and that dimension cannot separate the tiers. This repository's own model agrees: it has no `Environment` dimension. The nearest concept is the reef, which `docs/reef-substrate-model.md` treats as the environment or substrate boundary. railiance01 carries one reef, `reef-railiance`, so the reef cannot separate the tiers either. Readiness is recorded per binding (a rail hosted on a reef, a `rapp` bound to one), which is the axis that does. **Transition.** `rapp-policy-nexus` is `production-approved` but not yet managed by ArgoCD. Until 2026-12-21 its changes keep `activation=APPROVED` by founder plan approval, and each records that its target is production-tier. From its ArgoCD onboarding, due by 2026-12-21, the production row applies. The onboarding is owned by `railiance-platform`, and enforcement in the executor by `ops-mason`. Neither is work in this repository. **Open points referred to the custodian, not resolved here.** The decision sits on this ADR and the readiness contract, and four of its terms reach past what they define: 1. **Objects with no readiness state.** The decision puts platform objects that carry no readiness state in the production tier. The readiness contract defines states only for hosted rails and bound `rapp`s, and nothing here maps a Kubernetes object or namespace to a binding. The default is the founder's rule. It is not derivable from this contract. 2. **Evidence lapse.** The contract returns a binding to its last proven state when evidence fails or expires. Read with the table, a lapse would move a `production-approved` target back to the direct-apply row. The decision does not say whether a lapse loosens the change path. 3. **`deprecated`.** The table covers four of the five states. It does not place `deprecated`. 4. **The Tooling sentence.** The decision says the Kubernetes API "stays a Tooling contact, owned by `rail-kubernetes`". ADR-0009, Decision 4 keeps statute §20.3 unset: this repository will not imply a mapping of rails onto Taxonomy, Tooling, Engine or Staff. This revision therefore does not adopt that sentence. The custodian and `gate-house` should decide whether it is a §20.3 mapping or only a description of the contact. None of the four blocks the consequence above. Each needs a ruling before this ADR states more than the table.