9ba6e65654
Founder rulings: unmapped targets are production-tier until mapped; an evidence lapse does not loosen the path; deprecated keeps its tier. The contact is realm:kubernetes with no layer assigned (statute 20.3 stays unset per ADR-0009 D4). ArgoCD on railiance01 is unverified; until the production row has a working path, the transition rule covers every production-tier target. Resolves the conflict gate-house noted between the two founder records. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
42 lines
3.4 KiB
Markdown
42 lines
3.4 KiB
Markdown
# 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.
|