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