From 4e58927daca888a9a245f2eb5288fe27870eae61 Mon Sep 17 00:00:00 2001 From: codex Date: Mon, 21 Sep 2026 13:44:35 +0200 Subject: [PATCH] Record the operator's acceptance of ops-mason's plan-approval gate. Founder plan approval is accepted as the gate for ops-mason's phase-4 protected writes, as an operator-accepted exception to section 6.4, not a change to the standard. Review 2026-12-21. Co-Authored-By: Claude Opus 5 --- docs/ops-mason-plan-approval-gate-decision.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 docs/ops-mason-plan-approval-gate-decision.md diff --git a/docs/ops-mason-plan-approval-gate-decision.md b/docs/ops-mason-plan-approval-gate-decision.md new file mode 100644 index 0000000..74897aa --- /dev/null +++ b/docs/ops-mason-plan-approval-gate-decision.md @@ -0,0 +1,40 @@ +# ops-mason plan-approval gate: operator decision + +**Decided by:** Bernd Worsch, operator. **Date:** 2026-09-21. **Recorded by:** the-custodian. + +## Decision + +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` +- creating AppRole secret_ids +- `kubectl apply` of Kubernetes objects + +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. + +- §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. + +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. + +## 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. + +## 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. +- **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. +- **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. +- **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.