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