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

id	title	status	revision	owner	last_reviewed	review_interval
RMASTER-ADR-0006	Reef Production Admission	accepted	accepted-3	railiance-master	2026-09-21	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.

Who may reach a listener is a different axis: ADR-0008. 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). 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 @ <manifest repository>, 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 rapps, 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.