---
id: NK-WP-0027
type: workplan
title: "Reconcile reef placement and security-zone canon dependencies"
domain: infotech
repo: net-kingdom
status: blocked
owner: net-kingdom
topic_slug: netkingdom
planning_priority: P1
created: "2026-08-19"
updated: "2026-08-22"
state_hub_workstream_id: "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

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

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

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

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

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

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