tegwick
9e041e3662
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>
3.3 KiB
| id | type | title | domain | repo | status | owner | topic_slug | planning_priority | created | updated |
|---|---|---|---|---|---|---|---|---|---|---|
| NK-WP-0027 | workplan | Reconcile the reef taxonomy with the P and V ladders | infotech | net-kingdom | proposed | net-kingdom | netkingdom | P2 | 2026-08-19 | 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.
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.
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.
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.mdDecisions 4.6.1, 5.5, 8.4.1, 8.4.2repo-manager/docs/RailianceAppDeploymentGuide.md— reefs,bound_reefsrailiance-master/docs/adr/ADR-0006-reef-production-admission.md— topology is not readinesszone-engine/workplans/ZONE-WP-0001-security-zone-model.md— where the question came from, and why it is not answered there