From 398b91ce38965d170b165caba85927bdbc48aa8d Mon Sep 17 00:00:00 2001 From: tegwick Date: Mon, 21 Sep 2026 14:35:48 +0200 Subject: [PATCH] =?UTF-8?q?Record=20the=20founder's=20Kubernetes=20change?= =?UTF-8?q?=20gate=20and=20ops-mason's=20=C2=A76.4=20exception=20(GH-DEC-2?= =?UTF-8?q?026-022,=20GH-IN-0004).?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit No engine owns ops-mason's Kubernetes contact: the gate on ADMINISTER @ realm:kubernetes is quality, tiered by ADR-0006 readiness_state. Founder plan approval is recorded as an accepted exception against §6.4 obligation 1 and the §13.1 row, not a change to §6.4. No canon edited, no amendment drafted. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 63291@bnt-lap001 Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703 --- decisions/decisions.md | 191 +++++++++++++++++++++++++++++++++++++++++ intakes/intakes.md | 35 ++++++++ 2 files changed, 226 insertions(+) diff --git a/decisions/decisions.md b/decisions/decisions.md index 528d75f..d539ab3 100644 --- a/decisions/decisions.md +++ b/decisions/decisions.md @@ -3929,3 +3929,194 @@ turned out to have removed a wrong citation. `the-custodian` measured the eight and the checker split, and corrected its own count within a minute. `ops-warden` wrote the reference detector as steward's practice, left the open question visibly pending rather than deciding it in code, and the detector is adopted largely as written. + +## GH-DEC-2026-022 — ops-mason's Kubernetes contact: no engine owns it, and founder plan approval is an accepted exception to §6.4 + +```yaml +id: GH-DEC-2026-022 +kind: decision +title: 'ops-mason''s Kubernetes contact: no engine owns it, and founder plan approval + is an accepted exception to section 6.4' +status: resolved +owner: Bernd Worsch +repo: gate-house +standard: net-kingdom/canon/standards/security-layer-model_v0.7.md +source_note: the-custodian docs/kubernetes-change-gate-decision.md (the-custodian@e3d0d13); + the-custodian docs/ops-mason-plan-approval-gate-decision.md (the-custodian@4e58927, + terminology corrected at e3d0d13); ops-mason INTENT.md frontmatter (ops-mason@0ff263a); + ops-mason 696fa9e2; the-custodian 7a21dbfe and eba40030 +requested_dispositions: +- approved +- revised +- rejected +affects: +- gate-house +- ops-mason +- net-kingdom +- railiance-platform +- railiance-master +- rapp-policy-nexus +- access-engine +created: '2026-09-21T12:30:00.000000Z' +updated: '2026-09-21T12:30:00.000000Z' +rationale: 'Records two founder decisions of 2026-09-21, both taken by Bernd Worsch + exercising GOVERN @ estate, against gate-house''s statute. (1) ops-mason''s section + 5.3 gap kubernetes-plane-apply asked gate-house which engine, if any, should own + its contact with the Kubernetes API. None does. The gate on ADMINISTER @ realm:kubernetes + is a quality gate on a change, not an authorization decision, tiered by railiance-master + ADR-0006 readiness_state; no PDP belongs in the path. The gap stays declared with + intended_owner null by decision, which section 5.3 already accommodates as a permanent + operational necessity whose review keeps returning. (2) Founder plan approval (activation=APPROVED) + gating ops-mason''s phase-4 writes is a founder-accepted exception against section + 6.4 obligation 1 and ops-mason''s section 13.1 row. It is not a change to section + 6.4, ops-mason remains non-conformant there, and a conformance run reports the exception + as accepted, never as conformance. For kubectl apply, (1) narrows the exception + to targets below production-approved, the rapp-policy-nexus transition to 2026-12-21, + and BREAK_GLASS. No amendment is drafted. Nothing in net-kingdom canon is edited.' +decided_by: Bernd Worsch +decided_at: '2026-09-21T12:30:00.000000Z' +``` + +## Context + +ops-mason declared its NetKingdom layer at `ops-mason@0ff263a`. Its `INTENT.md` frontmatter +lists every direct Tooling contact as a §5.3 declared engine gap. One of them, +`kubernetes-plane-apply` (`src/ops_mason/kubernetes_plane.py`: server dry-run then apply of +an allowlisted, digest-pinned bundle), carries `intended_owner: null`. Its `blocked_on` says +Kubernetes is not catalogued in §4, that ops-mason reads the cluster as Tooling by character +(§3.2), and that the question was *"raised with gate-house as a catalog question"*. Gate House +had not recorded that question anywhere. It is opened and closed as `GH-IN-0004`. + +Separately, ops-mason answered gate-house's §6.4 obligation 3 note (`696fa9e2`): its stance is +undecided, not only unpublished, because phase-4 builds are gated by founder approval of a +construction plan (`plan.is_approved()`) and not by an `access-engine` decision. It recorded +`pep_stance: declared-gap`, review 2026-12-21. + +The founder decided both on 2026-09-21. The records are the custodian's, and this entry reads +from them, not from the hub messages that announced them. + +- `the-custodian/docs/ops-mason-plan-approval-gate-decision.md`: the plan-approval exception. +- `the-custodian/docs/kubernetes-change-gate-decision.md`: the Kubernetes change gate, which + answers the question the first record left open. + +Section numbers are those of the accepted v0.7. They are unchanged in the held v0.8 text. + +## Decision + +### 1. No engine owns ops-mason's Kubernetes contact + +**Answer to the §5.3 gap `kubernetes-plane-apply`: none.** Applying manifests to a running +cluster is `ADMINISTER @ realm:kubernetes/railiance01`. The gate on it is a **quality gate on a +change, not an authorization decision**. railiance-master ADR-0006 already keeps readiness and +permission on separate axes (`production-approved` "is not an authorization decision"), so no +policy decision point belongs in this path and `access-engine` is not its owner. The +Kubernetes API stays a Tooling contact, owned by `rail-kubernetes`. + +The gate is tiered by the target's ADR-0006 `readiness_state`, not by `Environment`, because +railiance01 is one cluster and every workload on it shares one `Environment`: + +| Readiness state of the target | Path for a change | `Activation` | +|---|---|---| +| `declared`, `installed`, `verified` | Direct `ADMINISTER @ realm:kubernetes` by ops-mason | `APPROVED`: founder approval of the construction plan | +| `production-approved` | `CONSTRUCT @ manifest repository`, reconciled by ArgoCD (`railiance-platform`) | `APPROVED` for the change; the merge is the gate | +| `production-approved`, emergency | Direct `ADMINISTER` | `BREAK_GLASS`, recorded, reconciled back into the repository afterwards | + +Platform objects with no readiness state default to the production tier. Production goes +through git for an `EvidenceBoundary` reason: a direct apply is `target-audited`, and a change +through the manifest repository adds `external-audited` evidence. That is a statement about +evidence, not about trust in ops-mason. + +**What this means for the gap, in §5.3's terms.** The contact stays a **declared gap**, and +`intended_owner: null` is now a decided value rather than an open one. §5.3 already names this +case: *"A permanent operational necessity is a declared gap whose review interval keeps +returning."* The gap is not converted into a standing allowance, and no fourth shape is +created, which §5.3 declines explicitly. ops-mason's `blocked_on` for this entry may now cite +the founder decision in place of the open catalog question. That edit is ops-mason's. + +The decision relies on the limits ops-mason's executor has today: one expected namespace per +plan, no `Pod` or `Secret` kinds, no manifest carrying `data` or `stringData`. Widening them is +a new decision, and gate-house would expect the §5.3 entry to be re-reviewed with it. + +### 2. Founder plan approval is an accepted exception to §6.4, not a change to it + +Recorded against **§6.4 obligation 1** and against **ops-mason's §13.1 row**. + +- **Covered:** ops-mason's phase-4 protected changes as declared at `ops-mason@0ff263a`: + writing OpenBao policies and auth roles on `auth/approle` and `auth/kubernetes`, creating + AppRole secret_ids, and `kubectl apply` of Kubernetes objects. For these, founder approval of + the construction plan (`activation=APPROVED`) is accepted as the gate, without an additional + `access-engine` decision. +- **Not a change to §6.4.** Obligation 1 still requires a PEP to act on a decision from + `access-engine` or on a recorded §9.3 stance. ops-mason meets neither, and this record does + not say it does. What changes is the status of the gap: undecided before, founder-accepted + now, with a reason and a review date. +- **§13.1.** ops-mason's row stays as written, not published and marked. Gate House reads it + with this exception beside it: the missing stance map is an **accepted** non-conformance + under §6.4 obligations 1 and 3, not an unexplained one. ops-mason's `pep_stance` stays + `declared-gap`. Nothing is added to the canon row. +- **Conditions:** the covered actions only; structure only, never secret values; the gaps stay + declared and a conformance run reports them as accepted exceptions, never as conformance; + review 2026-12-21, when the founder either renews the exception or asks for these writes to + route through `access-engine`. + +### 3. How the two compose + +For `kubectl apply`, decision 1 narrows the exception. Founder plan approval gates a direct +apply only where the target is below `production-approved`. A `production-approved` target, or +a platform object with no readiness state, takes the `CONSTRUCT` path through the manifest +repository, except under `BREAK_GLASS` and except for the `rapp-policy-nexus` 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 change records that its +target is production-tier, so the transition does not read as conformance. + +The OpenBao writes in the exception are untouched by decision 1. + +**A tension carried to the review.** At the 2026-12-21 review the exception offers a route +through `access-engine`. For the Kubernetes contact, decision 1 has already said no PDP belongs +in the path, so that route is closed there, and the review's real choice for `kubectl apply` +is to renew. The OpenBao writes keep both options. Gate House records this and rules nothing +on it now. + +### 4. No amendment is drafted + +Neither decision needs one to take effect. + +- The exception is a founder-accepted exception by its own terms. An amendment recognising + plan approval as PDP-equivalent under §6.4 would be a canon change, and nobody has proposed + it. Gate House does not propose it here. +- The §5.3 answer fits the text as written, including a null `intended_owner` for a permanent + necessity. + +One canon gap is noted and not drafted. Kubernetes is not catalogued in §4, yet decision 1 +treats it as Tooling owned by `rail-kubernetes`, and ops-mason declares the contact as §5.3 by +character. §5's scope rule reads "Tooling-layer system" as "catalogued as Tooling in §4". So a +§4 row for the Kubernetes API is the way to bring the contact under §5 deliberately, and that +is the only point where the canon lags this decision. It is not drafted now, because the v0.8 +hold is scoped to §11 (`GH-DEC-2026-019`) and ops-mason's declaration already closes the +practical gap. It is a candidate for the cut after v0.8. + +## What this does not rule + +- Whether ArgoCD is syncing on railiance01 today. The custodian could not check it, and + gate-house does not either. +- The ops-mason phase-4 readiness check, the ArgoCD onboarding of `rapp-policy-nexus`, and + ADR-0006's deploy-path consequence. They belong to ops-mason, railiance-platform, + rapp-policy-nexus and railiance-master. +- `GH-WP-0004-T08` (ops-mason's §11 declaration). It is related only because the same + frontmatter carries it. + +## Reversal condition + +Both decisions are the founder's, so gate-house does not reverse them. It returns decision 1 +to the founder if the gate on `ADMINISTER @ realm:kubernetes` comes to carry an authorization +question, for example if ops-mason's executor is widened to `Secret` kinds or to arbitrary +namespaces. That would bring an owning engine back into question. + +Decision 2 lapses at the 2026-12-21 review unless the founder renews it. + +## Provenance + +ops-mason declared the contact rather than treating it as out of scope, and named its own +open question in its `blocked_on` field instead of assigning an owner. The custodian recorded +both founder decisions and corrected its own first version's bare "operator" to the founder +exercising `GOVERN`. diff --git a/intakes/intakes.md b/intakes/intakes.md index 51a31db..6b3fa22 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -214,3 +214,38 @@ updated: '2026-09-21T00:00:00.000000Z' outcome: ruled state_hub_intake_id: "01a0c155-b5a3-7de4-b19f-12b1bc658729" ``` + +## GH-IN-0004 — Which engine, if any, should own ops-mason's contact with the Kubernetes API + +```yaml +id: GH-IN-0004 +kind: intake +title: Which engine, if any, should own ops-mason's contact with the Kubernetes API +status: closed +origin: cross-repo +origin_ref: ops-mason INTENT.md frontmatter, tooling_contacts kubernetes-plane-apply + (ops-mason@0ff263a) +priority: medium +owner: gate-house +requested_by: ops-mason +lane: red +description: 'ops-mason declares its kubectl apply contact (src/ops_mason/kubernetes_plane.py) + as a section 5.3 engine gap with intended_owner null. Its blocked_on says Kubernetes + is not catalogued in section 4, that ops-mason reads the cluster as Tooling by character + (section 3.2), and that the question was raised with gate-house as a catalog question. + Gate House had not recorded it until now. The earlier founder decision accepting + plan approval as the phase-4 gate (the-custodian docs/ops-mason-plan-approval-gate-decision.md) + left it open explicitly. + + + Closed by the founder''s decision of 2026-09-21, the-custodian docs/kubernetes-change-gate-decision.md + (the-custodian@e3d0d13), recorded here as GH-DEC-2026-022. No engine owns the contact. + The gate on ADMINISTER @ realm:kubernetes is a quality gate, not an authorization + decision, tiered by railiance-master ADR-0006 readiness_state. The section 5.3 gap + stays declared with intended_owner null by decision. A section 4 catalog row for the + Kubernetes API is noted in GH-DEC-2026-022 as a candidate for the cut after v0.8, + not drafted.' +created: '2026-09-21T12:30:00.000000Z' +updated: '2026-09-21T12:30:00.000000Z' +outcome: ruled +```