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