Record the founder's Kubernetes change gate and ops-mason's §6.4 exception (GH-DEC-2026-022, GH-IN-0004).
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 <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:
parent
8f035ee8be
commit
398b91ce38
2 changed files with 226 additions and 0 deletions
|
|
@ -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
|
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
|
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.
|
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`.
|
||||||
|
|
|
||||||
|
|
@ -214,3 +214,38 @@ updated: '2026-09-21T00:00:00.000000Z'
|
||||||
outcome: ruled
|
outcome: ruled
|
||||||
state_hub_intake_id: "01a0c155-b5a3-7de4-b19f-12b1bc658729"
|
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
|
||||||
|
```
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue