ZONE-WP-0001-T01: net-kingdom answered — separate standard, tenancy.yaml carrier, reefs struck

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 <noreply@anthropic.com>

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