Record the Kubernetes change gate in Mode of Authority terms; drop bare 'operator'.

Option C: the gate on ADMINISTER @ realm:kubernetes is tiered by ADR-0006
readiness state. Below production-approved, activation=APPROVED by founder
plan approval; at production-approved, CONSTRUCT via ArgoCD for
external-audited evidence, direct apply only as activation=BREAK_GLASS.
rapp-policy-nexus gets a dated transition to 2026-12-21.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/assessments/2026-09-21-layer-declaration-boundaries.md

@@ -218,7 +218,7 @@ names the defect generally. The custodian's contribution that survived is the
 - **secrets-engine** established that its exec reads the ungoverned legacy path
   `secret/coulomb/whynot-design/npm/publish` (field `npm_token`), while ops-warden's
   runbook rotates the governed path (field `NPM_AUTH_TOKEN`). A rotation per the
-  runbook would not reach the live publish path. Held for the operator.
+  runbook would not reach the live publish path. Held by the founder.
 
 Ten repositories still carry the pre-ruling sidecar form.
 
@@ -242,7 +242,7 @@ disk. The repositories' own reports had suggested a 3–3 split on the versioned
   v3 is not rolled out.
 - **tenant-engine** is admitted as an audit-core sender but cannot deliver:
   the egress NetworkPolicy, the URL, and the token projection are missing from
-  its deploy manifests. TEN-IN-0005; this needs an operator credential path.
+  its deploy manifests. TEN-IN-0005; this needs a credential path from custody (OpenBao, railiance-platform).
 - **secrets-engine** surfaced a question: the service JWT design names
   `tenant:coulomb`, but the approval chain resolved to `tenant:platform`.
 
@@ -288,7 +288,7 @@ Still open: A11 r2 and A12 r3 assent, INFD-IN-0007 (the §3 cut, outside the §1
 
 ## Follow-ups, 2026-09-21
 
-The operator approved A11 r2 and A12 r3. The approval was relayed to gate-house under GH-WP-0004-T09 as the return for the four round members that deferred to the operator: audit-core, access-engine, ops-warden and net-kingdom. It does not stand in for approval-engine, kings-guard, informed-decision or railiance-master.
+The founder approved A11 r2 and A12 r3, exercising `GOVERN`. The approval was relayed to gate-house under GH-WP-0004-T09 as the return for the four round members that deferred to the founder: audit-core, access-engine, ops-warden and net-kingdom. It does not stand in for approval-engine, kings-guard, informed-decision or railiance-master.
 
 GH-DEC-2026-021's immediate changes are applied:
 
@@ -296,3 +296,9 @@ GH-DEC-2026-021's immediate changes are applied:
 - **ops-warden** (`3979152`): the playbook is now titled as the estate reference detector. Prose citations are recorded as not reached, with a note of what widens if A12 r3 is rejected. `intent_version` is named as a key that must not be flagged.
 
 The reference detector flags a versioned path to any document, not only one naming the standard. GH-DEC-2026-021 §3 accepts that. No declaration carries such a path today.
+
+## Terminology, 2026-09-21
+
+This record and the custodian's messages today used bare "operator" for the founder's decisions. SecurityCanon's disambiguation rule forbids that: `Operator` is a CARING lifecycle role, and `OPERATE` is an Auth Mode. The founder's decisions today were authority over authority, which is `GOVERN`. The records are corrected. Messages already sent are not; later messages use the canon's terms.
+
+The Kubernetes change gate is recorded in `docs/kubernetes-change-gate-decision.md` in Mode of Authority terms.

docs/kubernetes-change-gate-decision.md

@@ -0,0 +1,60 @@
+# Kubernetes change gate: tiered by readiness state
+
+**Decided by:** Bernd Worsch (founder), exercising `GOVERN @ estate`. **Date:** 2026-09-21. **Recorded by:** the-custodian.
+
+**Vocabulary:** SecurityCanon Mode of Authority v0.2.0 (`security-canon/infospace/vocabulary/mode-of-authority/`), which is still a draft. Where that vocabulary changes, this record follows it.
+
+This record answers gate-house's open question: which engine, if any, should own ops-mason's contact with the Kubernetes API.
+
+## The question, stated in the canon's terms
+
+Applying manifests to a running cluster is `ADMINISTER @ realm:kubernetes/railiance01`. Changing the manifests is `CONSTRUCT @ <manifest repository>`. A GitOps controller separates the two: `CONSTRUCT` produces the definition, and the controller reconciles the cluster to it.
+
+The question is what gates `ADMINISTER @ realm:kubernetes`, and whether that gate differs between experimental and production workloads.
+
+## Decision
+
+1. **No engine owns the contact.** The gate 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 PDP belongs in this path. The Kubernetes API stays a Tooling contact, owned by `rail-kubernetes`.
+
+2. **The gate is tiered by ADR-0006 `readiness_state`, not by `Environment`.** railiance01 is a single cluster, and every workload on it shares one `Environment`. The canon's `Environment` dimension therefore cannot separate experimental from production here. The readiness state can.
+
+   | 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 that carry no readiness state default to the production tier.
+
+3. **Why production goes through git: the `EvidenceBoundary` dimension.** A direct apply is `target-audited`: the only evidence of the change is held by the realm being changed. A change through the manifest repository adds `external-audited` evidence, which survives the actor and the realm. For production that is the property that matters, and it is a statement about evidence, not about trust in ops-mason.
+
+## Transition for rapp-policy-nexus
+
+`rapp-policy-nexus` is `production-approved` (reef-railiance `bindings/rapps.yaml`), but ArgoCD does not manage it. Its `railiance-apps-root` applications are external-secrets, issue-core, openbao-secretstore and target-revenue. So the production path does not yet exist for the one workload that needs it.
+
+- **Until 2026-12-21:** changes to policy-nexus keep `activation=APPROVED` by founder plan approval. Each change additionally records that its target is production-tier, so the transition is visible and does not look like conformance.
+- **By 2026-12-21:** policy-nexus is onboarded to ArgoCD. From then on, the production row of the table applies to it.
+
+2026-12-21 is the same review date as the ops-mason plan-approval gate, so both come up together.
+
+## Scope of ops-mason's contact, as found
+
+ops-mason's executor is narrower than a generic `kubectl apply`:
+
+- it confines each plan to one expected namespace;
+- it refuses the `Pod` and `Secret` kinds;
+- it rejects any manifest carrying `data` or `stringData`.
+
+This decision relies on those limits. Widening them is a new decision.
+
+## Not verified here
+
+Whether ArgoCD is currently syncing on railiance01 could not be checked from the workstation, whose kube context is not the production cluster. The production row assumes ArgoCD works as its repository declares.
+
+## Owners
+
+- **gate-house:** the open question is answered. No engine owns the contact, and the gate is quality, not authorization.
+- **ops-mason:** phase 4 checks the target's readiness state and refuses a direct apply to a production-tier target, except under `BREAK_GLASS` or the policy-nexus transition.
+- **railiance-platform:** the ArgoCD lane is the production path, and policy-nexus onboarding is due by 2026-12-21.
+- **railiance-master:** ADR-0006 gains a deploy-path consequence for `production-approved`.
+- **rapp-policy-nexus:** the transition and its date.

docs/ops-mason-plan-approval-gate-decision.md

@@ -1,9 +1,11 @@
-# ops-mason plan-approval gate: operator decision
+# ops-mason plan-approval gate: founder decision
 
-**Decided by:** Bernd Worsch, operator. **Date:** 2026-09-21. **Recorded by:** the-custodian.
+**Decided by:** Bernd Worsch (founder), exercising `GOVERN @ estate`. **Date:** 2026-09-21. **Recorded by:** the-custodian.
 
 ## Decision
 
+_Terms follow SecurityCanon Mode of Authority v0.2.0 (draft), corrected on 2026-09-21 from a first version that used bare "operator", which the canon's disambiguation rule forbids._
+
 The founder's approval of an ops-mason construction plan (`plan.is_approved()`) is **accepted as the gate** for ops-mason's phase-4 protected changes. These are the changes it covers:
 
 - writing OpenBao policies, and auth roles on `auth/approle` and `auth/kubernetes`
@@ -14,27 +16,27 @@ These changes do not additionally require an access-engine decision.
 
 ## What kind of decision this is
 
-This is an **operator-accepted exception**, not a change to the standard.
+This is a **founder-accepted exception** (`GOVERN`: a decision about which constraint applies), not a change to the standard.
 
 - §6.4 obligation 1 of the security layer model still requires a PEP-shaped repository to act on a PDP decision.
 - ops-mason still does not meet that obligation, and this decision does not say that it does.
-- What changes is the status of the gap. It was undecided; it is now accepted by the operator, with a stated reason and a review date.
+- What changes is the status of the gap. It was undecided; it is now accepted by the founder, with a stated reason and a review date.
 
-Amending §6.4 to recognise operator plan approval as a PDP-equivalent would be a canon change. That goes through gate-house and net-kingdom, and nobody has proposed it.
+Amending §6.4 to recognise founder plan approval (`activation=APPROVED`) as PDP-equivalent would be a canon change. That goes through gate-house and net-kingdom, and nobody has proposed it.
 
 ## Why
 
-ops-mason's construction plans are drafted and self-reviewed by an agent, then approved by the founder before phase 4 runs. For the actions above, the founder is the deciding party, and the decision is made per plan, with the plan's content in view. The operator judges that an explicit, per-plan human approval is an adequate gate for these writes at the estate's current scale.
+ops-mason's construction plans are drafted and self-reviewed by an agent, then approved by the founder before phase 4 runs. For the actions above, the founder is the deciding party, and the decision is made per plan, with the plan's content in view. The founder judges that an explicit, per-plan human approval is an adequate gate for these writes at the estate's current scale.
 
 ## Conditions
 
-- **Only these changes are covered.** The exception covers the phase-4 actions listed above, as ops-mason declared them in its INTENT.md frontmatter on 2026-09-21 (ops-mason@0ff263a). A new class of protected change is not covered until the operator accepts it.
+- **Only these changes are covered.** The exception covers the phase-4 actions listed above, as ops-mason declared them in its INTENT.md frontmatter on 2026-09-21 (ops-mason@0ff263a). A new class of protected change is not covered until the founder accepts it.
 - **Structure only.** ops-mason's own declared capability is "structure only, never secret values". The exception depends on that holding.
-- **Review 2026-12-21.** That is the date ops-mason already set on the gaps. At review, the operator either renews the exception or asks for these writes to route through access-engine.
+- **Review 2026-12-21.** That is the date ops-mason already set on the gaps. At review, the founder either renews the exception or asks for these writes to route through access-engine.
 - **Still declared.** The gaps stay declared, not removed, and are marked accepted rather than open. A conformance run must report them as accepted exceptions, not as conformance.
 
 ## Consequences for other records
 
 - **ops-mason:** records the decision against its declared gaps and its `pep_stance` entry, which currently lists "remain founder-approval-gated only" as an open option.
-- **gate-house:** records it as an operator-accepted exception against §6.4 and the §13.1 stance-map row. The exception is noted in gate-house's own records, not in canon.
+- **gate-house:** records it as a founder-accepted exception against §6.4 and the §13.1 stance-map row. The exception is noted in gate-house's own records, not in canon.
 - **Kubernetes:** the question of which engine, if any, should own the `kubectl apply` contact stays open with gate-house. This decision accepts the gate for that contact; it does not name an owner.