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

id	type	title	domain	repo	status	flavor	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	backlog	residual	net-kingdom	netkingdom	P1	2026-08-19	2026-10-15	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: todo
blocked_on: message-from:repo-manager
blocking_reason: "Requires repo-manager acceptance of the reef provider carrier/schema, then railiance-infra authored ceilings, conditions and evidence in the authoritative reef declaration."
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: todo
depends_on: [NK-WP-0027-T02]
blocking_reason: "Mechanical join of reef ceilings to consumer V declarations waits on T02."
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: todo
blocked_on: message-from:info-tech-canon
blocking_reason: "Requires InfoTechCanon ruling on public disclosure classification versus synthetic provenance, then ops-warden authoritative dataclass_floor mapping and tests; no public-to-synthetic alias."
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 deliberately backlog following the October 15 owner prioritization below. The three open tasks are deferred as todo, with their owner dependencies preserved. Their completion is not required for current operations. State Hub treats wait as active work and would otherwise promote this plan back to active; todo records the intended dormant backlog state.

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

Infrastructure review — 2026-09-28

The current reef-railiance/declarations/reef.yaml still has no posture_provider block. Its ownership_repo is railiance-infra: involve that substrate owner alongside repo-manager (carrier/schema) in T02. The live cluster has one Ready node; all eight CNPG clusters report one instance. This supports retaining the single-failure-domain constraint, not assigning a new V level from replica counts. At that review, T02/T03 stayed wait; the October 15 backlog decision subsequently deferred them as todo.

InfoTechCanon Data Model §11.23 explicitly lists public; ops-warden registry/policy/security-posture.yaml still has no public maturity floor. The missing artifact is an owner-agreed mapping separating disclosure class from synthetic provenance, not proof that public exists. At that review T06 stayed wait; no public -> synthetic alias or guessed M1 floor is permitted.

Evidence and cross-plan priorities: estate review.

2026-10-11: demoted to flavor: residual / backlog by founder-authorized triage — off the critical path (identity → authz → secrets → SecurityCase execution). Tasks are unchanged; promote back when demand or risk appears. See the-custodian history/20261011-netkingdom-security-progress-assessment.md.

Resumption approach — 2026-10-15

Owner requested that this work remain in backlog after reviewing its value. From NetKingdom's point of view, the benefit is reliable policy input: a workload's availability claim must respect the substrate's evidenced ceiling, and disclosure classification must have an explicit maturity mapping. This work improves the accuracy of declarations and policy decisions; it does not itself add redundancy or improve uptime. For the current small team, pursue it when a concrete consumer needs the result rather than for declaration coverage alone.

Resume when a named deployment-admission or credential-policy consumer will use reef ceilings or the public-data maturity floor, or a concrete risk review identifies an overstated availability claim that needs mechanical prevention. Record the consumer, the decision it needs to make, its responsible owner, and the acceptance example before promoting the plan. Do not infer renewed demand merely from the presence of unfinished tasks.

Start from the existing proposal, docs/reef-posture-provider-contract.md, and recheck current owner sources. On October 15, the authoritative reef-railiance/declarations/reef.yaml still has no posture_provider block; InfoTechCanon's Data Model includes public, while ops-warden's registry/policy/security-posture.yaml still has no public maturity floor. These source checks establish the outstanding artifacts, not owner acceptance of the proposal or a fresh runtime topology measurement.

Use this sequence when picking the work up:

1. Settle the reef contract (T02). Prepare a concrete schema/declaration change with repo-manager and railiance-infra. Repo-manager accepts the authoritative carrier and field names; railiance-infra owns the ceiling, consumer conditions, current evidence and review dates. Treat the proposed V0 available / V1 maximum as a starting proposal requiring current owner evidence. Record acceptance in owner source before adopting the contract.
2. Implement and exercise the join (T03). NetKingdom owns posture semantics and the reconciler. Resolve placement from authoritative declarations, compose availability across synchronous providers, and preserve satisfied, unsatisfied and unknown. Test claims above the ceiling, missing or stale evidence, and unmet recovery conditions. Exercise the accepted contract against the named consumer and retain reproducible declaration revisions and results before marking this task done.
3. Resolve classification and map it (T06). Obtain InfoTechCanon's recorded ruling separating public disclosure from synthetic provenance. Then have ops-warden adopt the authoritative maturity mapping and test its consumer behavior. The existing public -> M1 suggestion remains a proposal; do not alias public to synthetic or silently guess a floor.
4. Close on owner artifacts and consumer evidence. Reconcile all three tasks against the accepted declarations, implementation and tests; update source statuses and run statehub fix-consistency --repo net-kingdom. Mark the plan finished only when those artifacts exist.

The reef and classification owner discussions can proceed independently once work is resumed. No cluster expansion is a prerequisite: the first useful result may correctly document and enforce the existing single-domain limit. Any subsequent runtime or admission-policy activation must follow the named consumer owner's rollout contract. Until then, unresolved facts remain unknown; backlog status supplies no new policy exception or permission.