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>
82 lines
3.3 KiB
Markdown
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
|