From 468e0d3321d6d4d5cdd90fe43a7116f734f413d8 Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 19 Aug 2026 22:06:32 +0200 Subject: [PATCH] =?UTF-8?q?ZONE-WP-0001-T01:=20net-kingdom=20answered=20?= =?UTF-8?q?=E2=80=94=20separate=20standard,=20tenancy.yaml=20carrier,=20re?= =?UTF-8?q?efs=20struck?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Amended by net-kingdom as canon owner of tenancy-posture_v0.1. T01: enforcement stance is a sibling canon standard, not a seventh axis (the six ladders are monotone and stance is not; and a descriptive framework cannot carry a prescriptive axis without handing out its own exemptions). Ownership confirmed; the repo is not archived. Declaration surface is tenancy.yaml's reserved zones: key, not a new root file. T02: the reef question is struck — the unreconciled pair is reef vs P/V and it is canon's defect (NK-WP-0027), not this model's scope. organization_posture: do not fold in, consume as an input. T05: carrier file settled; only the shape inside zones: remains open. Co-Authored-By: Claude Opus 5 --- workplans/ZONE-WP-0001-security-zone-model.md | 104 +++++++++++++++++- 1 file changed, 98 insertions(+), 6 deletions(-) diff --git a/workplans/ZONE-WP-0001-security-zone-model.md b/workplans/ZONE-WP-0001-security-zone-model.md index 9f41762..96bc51b 100644 --- a/workplans/ZONE-WP-0001-security-zone-model.md +++ b/workplans/ZONE-WP-0001-security-zone-model.md @@ -112,6 +112,84 @@ The invariant flex-auth confirms is the tighter one: Rationale is in T03. Please carry the tightened wording into `GOAL.md`; the current wording is not wrong, it is just not load-bearing. +**net-kingdom answered 2026-08-19 (amended by net-kingdom, as canon owner of +`tenancy-posture_v0.1`).** Confirmed on both counts, and one part of the +question is taken off this repo. + +**1. Enforcement stance is a separate standard, not a seventh axis of +`tenancy-posture`.** Recorded as that standard's Decision 5.6 (draft-9). The +reason is structural, not territorial, and it matters for how the zone model is +shaped: + +- **Every one of the six axes is monotone** — higher is stronger and higher is + what a service wants. `current`/`target`/`gap`, §12's *improve* and *guard* + steps, and §6's special allowance for a permanently-low level all depend on + it. **Enforcement stance is not monotone.** `ADR-0006` is precisely the + finding that the top rung is the wrong answer for the SSH lane the tunnels + depend on. A ladder whose top is sometimes wrong is an enumeration, and + embedding one in the vector would break the six that are ladders. §8.3 + refused a QoS axis on a weaker version of this test. +- **`tenancy-posture` is descriptive; stance is prescriptive.** §6 is *accuracy, + not altitude*, and it is safe only because the framework blocks nothing by + itself. Prescription enters through Decision 8.2, where a **requirer** sets a + minimum and a machine reconciles it against declarations. Fold stance in as an + axis and an accurately declared `exempt` becomes conformant *and* exempt — a + conformance rule handing out the exemption it exists to audit. + +This is the same split flex-auth argued in T03, arrived at from the canon side: +**membership is data and is declared; stance is a rule and belongs to the +control's owner.** Membership behaves like a level. Stance behaves like a tier +minimum. + +**Binding on the declaration format (this pre-empts part of T05).** To avoid the +parallel-framework outcome this message was sent to prevent, canon rules that +**zone membership is declared in `tenancy.yaml` under a reserved top-level +`zones:` key** — sibling to `tenancy:` and `provider:`, never inside +`tenancy.current`. §5.4 makes that file the repo's single posture declaration +surface and a second root file recreates the divergence §5.4 ended. The key is +already reserved in `canon/schemas/tenancy-posture_v0.1.schema.json` and is +deliberately unconstrained there, so the validator will not reject a combined +declaration while `security-zones_v0.1` is still being drafted. One file, one +review cadence, one validator; two standards, because they have different owners +and different conformance semantics. + +**On `organization_posture` (asked in T02 and in `WARDEN-WP-0032-T01`):** it does +not belong in a per-repo declaration under either key. It is a fleet-wide, +time-varying scalar describing the *estate*, not a property of the declaring +service, and a per-repo copy of a global goes stale in as many places as there +are repos. Read it as an **input** to stance selection; do not absorb it. + +**2. Reefs — `zone-engine` is right, and the reconciliation is not yours.** +*Placement is not posture* is correct and should stay. But the pairing has been +misidentified: the unreconciled pair is not zone ↔ reef, it is **reef ↔ `P` and +`V`**, and it is a defect in `tenancy-posture`, not a gap in the zone model. +`P` grades tenant data isolation *within a datastore*; a reef is a named compute +substrate with an accepted residual risk, and there is no rung for that. The +live consequence is on `V`: `reef-railiance` is single-node with a shared +control plane, which caps `V` for everything bound to it under Decision 4.6.1, +and nothing joins those facts today. That is Decision 5.5's provider-declaration +finding one layer down — a reef is a provider with nowhere to state what it +makes reachable. + +Recorded as `tenancy-posture` Decisions 8.4.1 and 8.4.2 and taken as +`net-kingdom`'s `NK-WP-0027`. **`ZONE-WP-0001` is not blocked on it.** Delete the +reef question from T02's list of things this model must answer; citing +Decision 8.4.1 is sufficient. + +One further canon ruling, because three repos had written the same rule in three +vocabularies — *topology is not readiness* (`railiance-master`), *placement is +not posture* (here), and §3.1's naming requirement. Decision 8.4.1 now states it +once: **the substrate a workload sits on is never, by itself, evidence for a +level on any ladder.** Cite it rather than restating it locally. + +**Ownership confirmed.** `zone-engine` owns zone identity, membership and the +exception lifecycle. Canon publishes `security-zones_v0.1.md` beside +`tenancy-posture_v0.1` and the `*-engine` boundary contracts, owner-driven, as +WP-0015's maturity model was. The repo is not archived. + +Carry into `GOAL.md`: the tightened flex-auth invariant, and that the declaration +surface is `tenancy.yaml`'s `zones:` key rather than a new file. + ```task id: ZONE-WP-0001-T02 status: todo @@ -132,11 +210,15 @@ Answer explicitly: is real and hardest to model. A time-boxed relaxation is a *different object* from a standing zone; conflating them yields a permanent hole with a temporary-sounding name. -- Do zones **compose with or fold in** the three existing axes? A fourth - independent axis multiplies states; absorbing `organization_posture` may be - the honest move. -- How do zones relate to **reefs**? State it in the model rather than leaving - readers to guess. +- ~~How do zones relate to **reefs**?~~ **Struck by net-kingdom 2026-08-19.** + Not this model's question. Cite `tenancy-posture` Decision 8.4.1 — substrate + location is never by itself evidence for a level — and stop there. The real + unreconciled pair is reef ↔ `P`/`V` and it is canon's, tracked as `NK-WP-0027`. +- ~~Do zones **compose with or fold in** `organization_posture`?~~ **Answered by + net-kingdom 2026-08-19:** do not fold it in. It is a fleet-wide time-varying + scalar, not a per-service property; consume it as an input to stance selection. + The *other* two axes (environment posture, `M0`–`M3`) remain an open question + for this task — they are per-workload and genuinely composable. ```task id: ZONE-WP-0001-T03 @@ -253,6 +335,14 @@ with evidence, `reviewed`, and `review_due`; carry over *accuracy, not altitude*. Include how a zone assignment changes and how that change is observed — a zone that can be quietly widened is not a boundary. +**Carrier file settled by net-kingdom 2026-08-19 (see T01).** The declaration +rides `tenancy.yaml` under a reserved top-level `zones:` key, not a new root +file. The key is already permitted and deliberately unconstrained in +`net-kingdom/canon/schemas/tenancy-posture_v0.1.schema.json`, so this task +defines the shape inside `zones:` and nothing else. What remains open here is +unchanged: the `trust_zone` collision, and whether membership rides the subject +or the resource. + **Two carrier facts from flex-auth 2026-08-19 (no schema change needed).** Compiled zone membership is expressible in flex-auth's registry format **today**, with zero Go changes. Every registry entity carries `metadata`; `api.Resource` @@ -315,5 +405,7 @@ cheap by design. The second consumer comes from T01. - ops-warden `WARDEN-WP-0032` — the ops-warden-side stub this was ported from - ops-warden `WARDEN-WP-0031` — the deferred flip, and the readiness evidence - flex-auth `FLEX-WP-0016` — the enforcing pin with no enforcing consumer -- `net-kingdom/canon/standards/tenancy-posture_v0.1.md` +- `net-kingdom/canon/standards/tenancy-posture_v0.1.md` — draft-9 Decisions 5.6, + 8.4.1, 8.4.2 are net-kingdom's answer to T01 +- `net-kingdom` `NK-WP-0027` — the reef ↔ `P`/`V` reconciliation, taken off this repo - `repo-manager/docs/RailianceAppDeploymentGuide.md` — reefs