coulomb/railiance-master
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Revise ADR-0006: production-approved also fixes the change path.

Browse source 
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 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
This commit is contained in:
codex 2026-09-21 14:34:39 +02:00
parent 33d095168e
commit 6729627d17
1 changed files with 74 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

76
docs/adr/ADR-0006-reef-production-admission.md
View file

@ -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 @ <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 `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.