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

ops-mason plan-approval gate: founder decision

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
• 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 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 founder, with a stated reason and a review date.

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 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 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 founder either renews the exception or asks for these writes to route through access-engine. That choice does not extend to kubectl apply: docs/kubernetes-change-gate-decision.md ruled it a quality gate, not an authorization decision, so it never routes through access-engine. gate-house GH-DEC-2026-022 noted the conflict between the two records, and this sentence resolves it.
• 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 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.