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

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	created	updated	state_hub_workstream_id
NK-WP-0027	workplan	Reconcile reef placement and security-zone canon dependencies	infotech	net-kingdom	blocked	net-kingdom	netkingdom	P1	2026-08-19	2026-08-22	965ad365-6b81-50a1-a2a3-2d0c1fcce0b4

NK-WP-0027 — Reefs, placement, and security-zone canon dependencies

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.

Activation review — 2026-08-22

The original reef finding remains valid and correctly owned. Review against draft-9 found T01 substantially written already in Decision 8.4.2, but the text did not explicitly say which Decision 3.2 couplings a reef binding fails to satisfy. Draft-10 now closes that textual gap. T02 and T03 remain real: the reef provider declaration and its mechanical join to consumer V do not yet exist.

The review also took in a second canon question handed over by ZONE-WP-0001-T03. Measured coverage is nine declared rapp workloads, one of 27 credential lanes joinable, 13 plausible but undeclared consumers, and 13 operational controls with no workload-shaped path. The ruling is recorded as Tenancy Posture Decision 5.6.1:

• the workload remains the sole policy subject;
• workload includes independently governed application, automation, and operational/control-plane execution units behind SSH, tunnels, brokers, credential flows, policy machinery, and maintenance activity;
• lanes, grants, patterns, repositories, actors, and packages do not become substitute policy subjects;
• every managed deployable, including operational/tooling runtimes, resolves through its authoritative rapp declaration; a real operational execution unit that is not a managed deployable may declare locally; and
• absent authoritative identity or membership resolves to unknown, never an inferred or silently permissive zone.

An explicit control rule may decide how to treat unknown; that is stance and does not manufacture membership. This preserves the build-stage flexibility already accepted by ADR-0006 without encoding it as a false zone fact.

T01 — Establish the reef and P boundary

id: NK-WP-0027-T01
status: done
priority: medium
state_hub_task_id: "d88714a4-0bcb-567e-8542-d5b4c556b8ec"

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.

Done 2026-08-22. Tenancy Posture Decision 8.4.2 now says explicitly that a reef binding records compute substrate and accepted residual risk, satisfies no P coupling by itself, and participates only as a possible V ceiling across the critical path.

T02 — Extend provider declarations to reefs

id: NK-WP-0027-T02
status: wait
priority: medium
state_hub_task_id: "5b35b646-a525-55da-852a-6005613d42ea"

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.

In progress 2026-08-22. The canon-side boundary and proposed provider shape are ready. Agreement and the authoritative reef declaration surface remain with repo-manager.

Contract proposal 2026-08-22. docs/reef-posture-provider-contract.md now proposes a posture_provider block inside authoritative declarations/reef.yaml, reusing Decision 5.5's available/maximum/conditions/evidence semantics. For reef-railiance it proposes V0 available and V1 maximum: no unconditional reusable recovery guarantee exists, while a named workload can evidence restart/recreate recovery inside the one failure domain. The field name and reef-schema adoption remain subject to repo-manager agreement.

Waiting: repo-manager must confirm or amend the reef.yaml carrier, field name, and conservative V0/V1 values. NetKingdom cannot make that reef-vocabulary decision on its behalf.

T03 — Reconcile reef ceilings mechanically

id: NK-WP-0027-T03
status: wait
priority: low
state_hub_task_id: "e3f0bb0f-0c85-5cb9-a5ab-75f668cd3447"

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.

Design advanced 2026-08-22. The proposal defines a three-valued join: satisfied, unsatisfied, or unknown. It rejects claims above the reef maximum, requires condition evidence above its unconditional available level, and composes V across synchronous providers. Implementation still waits on the authoritative reef field name from T02.

T04 — Rule on zone policy subject and absence

id: NK-WP-0027-T04
status: done
priority: high
state_hub_task_id: "132658cb-5ea0-528c-86e2-095254c36cd7"

Rule on the security-zone policy subject and absence semantics for ZONE-WP-0001-T03. Keep workload as the sole subject, define it broadly enough to cover operational/control-plane execution, and state whether missing identity or membership may inherit a zone.

Done 2026-08-22. Decision 5.6.1 defines operational execution units as workloads, rejects lanes/actors/patterns as substitute subjects, and requires unresolved membership to return unknown without inference. A control may apply an explicit fail-safe stance to unknown; it may not relabel it.

T05 — Broaden workload declaration coverage

id: NK-WP-0027-T05
status: done
priority: high
state_hub_task_id: "d60e209d-3090-59e7-afc4-0a3780507403"

Broaden authoritative workload declaration coverage beyond managed rapp applications. In the security-zones_v0.1 publication review, require a stable workload identity and responsible party for operational/control-plane units, and a machine-readable join from credential/control resources to the workload they serve. Require the authoritative rapp declaration for managed deployables, but do not invent a workload or rapp for native non-workload subjects or independently governed units that are not managed deployables. Do not infer the join from path strings or repository ownership. Coordinate the declaration boundary with zone-engine, repo-manager, and the affected control owners.

Done 2026-08-22. Tenancy Posture draft-12 Decision 5.6.2 and its schema now require workload_identity whenever a zones: block is present. The binding names the stable workload id, kind, responsible repo, and one or more exact authority/subject/principal-type tuples. Multi-service declarations carry both fields per service; top-level multi-service membership is rejected. Following RMGR-ADR-004, every managed deployable uses its authoritative rapp declaration and consumer references use (rapp_id, workload_identity.name) plus optional deployable. Only a non-managed operational execution unit declares locally; native actions, actors, lanes, patterns, and resources are explicitly not-applicable, while omissions stay unknown. The published canon/standards/security-zones_v0.1.md proposal now has a closed schema shape for its five memberships, admission context, evidence, and review dates. The validator rejects service/id mismatch, duplicate bindings, and invalid review windows; tests cover missing identity and a valid operational workload.

T06 — Resolve the DataClassification mismatch

id: NK-WP-0027-T06
status: wait
priority: high
state_hub_task_id: "bf8b3e1d-7ee0-5ad0-8705-5a580a9fb546"

Resolve the DataClassification vocabulary mismatch surfaced by ZONE-WP-0001-T03. rapp-policy-nexus declares public, while ops-warden's dataclass_floor maps only synthetic, internal, confidential, and restricted. Do not alias public to synthetic: public describes disclosure policy, while synthetic describes data origin and whether values are real. Route the vocabulary decision to info-tech-canon, which owns DataClassification, and then update the workload-maturity mapping with its ruling. Until the mapping is authoritative, a compiler must report the maturity floor as unresolved rather than guess.

Routed 2026-08-22. The mismatch and non-equivalence are confirmed; owner consultation is sent and the downstream mapping is pending.

Waiting: info-tech-canon owns DataClassification and must rule its ordering relative to synthetic-data provenance. The proposed downstream public -> M1 mapping remains explicitly non-authoritative until that answer.

Current gate

The zone-engine publication candidate at a510393 has been reviewed and published as the proposed NetKingdom security-zones_v0.1 standard. All locally actionable canon and schema work is complete. The remaining chain is externally owned:

1. repo-manager agrees or amends the reef.yaml provider carrier (T02).
2. NetKingdom implements the mechanical reef ceiling join against that accepted carrier (T03).
3. info-tech-canon rules the public/synthetic relationship, after which ops-warden can update dataclass_floor (T06).

The workplan is blocked rather than left nominally active with every open task at wait. No human intervention is required yet; owner responses are the ordinary next input.

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
• zone-engine/docs/exception-lifecycle-2026-08-22.md — already requires authoritative workload ids and fail-safe exception evaluation
• docs/reef-posture-provider-contract.md — concrete T02/T03 carrier and join proposal awaiting reef-owner agreement