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

46 lines
1.4 KiB
Markdown

---
id: RMASTER-ADR-0006
title: "Reef Production Admission"
status: accepted
revision: "accepted-1"
owner: railiance-master
last_reviewed: "2026-08-15"
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.
## 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.