tenancy-posture draft-9: enforcement stance is not a seventh axis; reefs are canon's defect

Answers zone-engine ZONE-WP-0001-T01.

Decision 5.6 — enforcement stance is a sibling standard, not an axis. The six
ladders are monotone and the whole current/target/guard machinery depends on it;
enforcement stance is not (ADR-0006 is the finding that the top rung is wrong for
the SSH lane). And this framework is descriptive: an accurately declared exempt
would be conformant and exempt. Membership is declared, stance belongs to the
control owner. Zone membership rides tenancy.yaml under a reserved zones: key so
the estate keeps one declaration surface; the schema permits it, unconstrained.

Decisions 8.4.1/8.4.2 — 'substrate location is not evidence' stated once instead
of three repo-local slogans, and the reef/P/V gap recorded as this document's
defect rather than zone-engine's scope. NK-WP-0027 takes it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/NK-WP-0027-reef-placement-reconciliation.md

@@ -0,0 +1,82 @@
+---
+id: NK-WP-0027
+type: workplan
+title: "Reconcile the reef taxonomy with the P and V ladders"
+domain: infotech
+repo: net-kingdom
+status: proposed
+owner: net-kingdom
+topic_slug: netkingdom
+planning_priority: P2
+created: "2026-08-19"
+updated: "2026-08-19"
+---
+
+# NK-WP-0027 — Reefs, placement, and what a substrate makes reachable
+
+Raised by answering `zone-engine`'s `ZONE-WP-0001-T01`. `zone-engine` asked
+whether canon should reconcile security zones with reefs, expecting the answer
+to enlarge *its* scope. It does not: a zone is genuinely not a reef, and
+`zone-engine` should keep *placement is not posture* and move on. The
+unreconciled pair is **reef ↔ `P` and `V` in `tenancy-posture_v0.1`**, and it
+is this repo's defect, recorded as Decision 8.4.2 in draft-9.
+
+`repo-manager` owns substrate placement (`reef-railiance`, `reef-storage`) with
+residual-risk acceptance attached to a binding. §7 and §8 of the standard
+presuppose placement is fully described by the `P` ladder. `P` grades tenant
+data isolation *within a datastore*; a reef is a named compute substrate
+carrying an accepted residual risk. There is no rung for "single node, shared
+control plane, risk accepted", and there should not be one — inventing it is
+the fabrication §6 prohibits.
+
+The live consequence is on `V`. Decision 4.6.1 makes `V` the minimum across the
+synchronous path and says a replica count is not evidence. `reef-railiance` is
+single-node with a shared control plane and therefore caps `V` for everything
+bound to it. Nothing joins those facts today, so a rapp can declare `V2`
+accurately by its own reading and be wrong by the standard's own composition
+rule. This is Decision 5.5's provider-declaration finding one layer down: a
+reef is a provider with nowhere to say what it makes reachable.
+
+```task
+id: NK-WP-0027-T01
+status: todo
+priority: medium
+```
+
+**Establish the boundary between a reef and the `P` ladder in canon text.** Say
+what each answers, why a reef is not a `P` level, and which of `P`'s couplings
+(§3.2) a reef binding does and does not satisfy. Do not extend the `P` ladder.
+
+```task
+id: NK-WP-0027-T02
+status: todo
+priority: medium
+```
+
+**Extend Decision 5.5's provider declaration to substrate providers, and agree
+it with `repo-manager`.** A reef should state, per axis it bounds, the maximum
+level it makes reachable and what a consumer must do to reach it — the same
+sentence `apps-pg` now owes its consumers. `reef-railiance`'s first line is
+almost certainly a `V` ceiling. This is a proposal to `repo-manager`, not a
+canon fiat: it owns the reef vocabulary and the acceptance record.
+
+```task
+id: NK-WP-0027-T03
+status: wait
+priority: low
+```
+
+**Join reef ceilings to consumer `V` declarations mechanically.** Waits on T02.
+Decision 8.2's pattern applies — the requirer asserts, the declarer declares,
+a machine reconciles. Until then a consumer bound to a reef declares `V` with
+the reef named as a synchronous dependency, which is already required by
+Decision 4.6.1 and is not being done.
+
+## Related
+
+- `canon/standards/tenancy-posture_v0.1.md` Decisions 4.6.1, 5.5, 8.4.1, 8.4.2
+- `repo-manager/docs/RailianceAppDeploymentGuide.md` — reefs, `bound_reefs`
+- `railiance-master/docs/adr/ADR-0006-reef-production-admission.md` — topology
+  is not readiness
+- `zone-engine/workplans/ZONE-WP-0001-security-zone-model.md` — where the
+  question came from, and why it is not answered there