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	a30a33e4-f980-4934-9efb-d61a75e6ae81

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: "a1dfa4ec-f946-425e-8183-782eef7763c4"

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: "601a0c5f-3f77-419f-9731-25e247424b31"

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: "b53bfb83-1df9-4548-a62f-628cb55ece4d"

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

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

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. Do not require rapp packaging merely to gain identity, and 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

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