net-kingdom/workplans/NK-WP-0027-reef-placement-reconciliation.md
tegwick 9e041e3662
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
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>
2026-08-19 22:06:20 +02:00

82 lines
3.3 KiB
Markdown

---
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