From 6729627d174afaff4501ccb798c6788aa3314bbf Mon Sep 17 00:00:00 2001 From: codex Date: Mon, 21 Sep 2026 14:34:39 +0200 Subject: [PATCH] Revise ADR-0006: production-approved also fixes the change path. Record the founder's Kubernetes change-gate decision (2026-09-21, GOVERN @ estate) as revision accepted-3. At production-approved, changes go through CONSTRUCT @ manifest repository, reconciled by ArgoCD, which is external-audited. A direct ADMINISTER is allowed only with activation=BREAK_GLASS. The change path is still not an authorization decision. Four open points are referred to the custodian and not resolved. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 63291@bnt-lap001 Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703 --- .../adr/ADR-0006-reef-production-admission.md | 76 ++++++++++++++++++- 1 file changed, 74 insertions(+), 2 deletions(-) diff --git a/docs/adr/ADR-0006-reef-production-admission.md b/docs/adr/ADR-0006-reef-production-admission.md index fc98cf3..9b421e4 100644 --- a/docs/adr/ADR-0006-reef-production-admission.md +++ b/docs/adr/ADR-0006-reef-production-admission.md @@ -2,9 +2,9 @@ id: RMASTER-ADR-0006 title: "Reef Production Admission" status: accepted -revision: "accepted-2" +revision: "accepted-3" owner: railiance-master -last_reviewed: "2026-08-29" +last_reviewed: "2026-09-21" review_interval: 6m --- @@ -50,3 +50,75 @@ actor may perform an action on a resource is `access-engine` - `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.