# 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.