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
|
||||
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`.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue