docs(canon): reconcile workload and tenant grouping semantics
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a02929-244b-7391-b933-c04010e8eedb
This commit is contained in:
parent
ad2057acff
commit
bee22db620
21 changed files with 1118 additions and 59 deletions
|
|
@ -1,18 +1,19 @@
|
|||
---
|
||||
id: NK-WP-0027
|
||||
type: workplan
|
||||
title: "Reconcile the reef taxonomy with the P and V ladders"
|
||||
title: "Reconcile reef placement and security-zone canon dependencies"
|
||||
domain: infotech
|
||||
repo: net-kingdom
|
||||
status: proposed
|
||||
status: blocked
|
||||
owner: net-kingdom
|
||||
topic_slug: netkingdom
|
||||
planning_priority: P2
|
||||
planning_priority: P1
|
||||
created: "2026-08-19"
|
||||
updated: "2026-08-19"
|
||||
updated: "2026-08-22"
|
||||
state_hub_workstream_id: "a30a33e4-f980-4934-9efb-d61a75e6ae81"
|
||||
---
|
||||
|
||||
# NK-WP-0027 — Reefs, placement, and what a substrate makes reachable
|
||||
# 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
|
||||
|
|
@ -37,20 +38,61 @@ 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: todo
|
||||
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
|
||||
|
||||
```task
|
||||
id: NK-WP-0027-T02
|
||||
status: todo
|
||||
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
|
||||
|
|
@ -60,10 +102,30 @@ 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: "b53bfb83-1df9-4548-a62f-628cb55ece4d"
|
||||
```
|
||||
|
||||
**Join reef ceilings to consumer `V` declarations mechanically.** Waits on T02.
|
||||
|
|
@ -72,6 +134,104 @@ 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
|
||||
```
|
||||
|
||||
**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
|
||||
```
|
||||
|
||||
**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
|
||||
|
||||
```task
|
||||
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
|
||||
|
|
@ -80,3 +240,7 @@ Decision 4.6.1 and is not being done.
|
|||
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
|
||||
|
|
|
|||
|
|
@ -0,0 +1,80 @@
|
|||
---
|
||||
id: NK-WP-0028
|
||||
type: workplan
|
||||
title: "Publish zone canon and clarify tenant grouping semantics"
|
||||
domain: infotech
|
||||
repo: net-kingdom
|
||||
status: finished
|
||||
owner: codex
|
||||
topic_slug: netkingdom
|
||||
planning_priority: P1
|
||||
created: "2026-08-22"
|
||||
updated: "2026-08-22"
|
||||
---
|
||||
|
||||
# NK-WP-0028 — Canon publication and grouping semantics
|
||||
|
||||
Authorized by the operator on 2026-08-22 after repository triage. This work
|
||||
publishes the zone-engine owner draft, reconciles its authoritative workload
|
||||
reference semantics with Tenancy Posture, resolves ADR-0013's now-load-bearing
|
||||
grouping ambiguity, and makes the existing ADR set publication-addressable.
|
||||
|
||||
## Publish and integrate Security Zones v0.1
|
||||
|
||||
```task
|
||||
id: NK-WP-0028-T01
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
Reviewed zone-engine revision `a510393` against Tenancy Posture Decisions 5.6.1
|
||||
and 5.6.2 and RMGR-ADR-004. Published it as proposed canon at
|
||||
`canon/standards/security-zones_v0.1.md`, retaining workload-only zone
|
||||
membership, explicit `not-applicable` for native non-workload subjects, and
|
||||
`unknown` for missing or ambiguous workload references. Replaced the tenancy
|
||||
schema's placeholder `zones:` object with the standard's five memberships,
|
||||
admission context, evidence, and review fields.
|
||||
|
||||
## Clarify current grouping versus historical identifier segment
|
||||
|
||||
```task
|
||||
id: NK-WP-0028-T02
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
Amended NK-ADR-0013 so the immutable tenant identifier retains its
|
||||
onboarding-time grouping segment as history while `tenant-engine.grouping` is
|
||||
the mutable, authoritative current classification. Consumers may not derive
|
||||
current policy, guardrail, or spend-ceiling inputs by splitting a tenant id.
|
||||
Propagated the ruling to IAM Profile v0.3 and the Tenant Engine Boundary
|
||||
Contract.
|
||||
|
||||
## Add publication metadata and ignore generated architecture cache
|
||||
|
||||
```task
|
||||
id: NK-WP-0028-T03
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Added unique `NK-ADR-*` identifiers plus owner, revision, review date, and
|
||||
review interval metadata to ADR-0006 through ADR-0015 that exist in this repo.
|
||||
Recorded the security-zone source revision and added the generated architecture
|
||||
AST cache to `.gitignore`.
|
||||
|
||||
## Verification
|
||||
|
||||
```task
|
||||
id: NK-WP-0028-T04
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Verified the JSON schema parses, all 14 tenancy-posture unit tests pass, and the
|
||||
repository diff has no whitespace errors. Seven estate declarations were also
|
||||
checked: five validate; the previously-routed flex-auth `implemented A2` drift
|
||||
and railiance-platform apps-pg R2/V1 evidence drift remain owner work and are
|
||||
not regressions from this change. Workplan state was reconciled with State Hub.
|
||||
Remaining external decisions stay tracked as waits in NK-WP-0027 and
|
||||
NK-WP-0022.
|
||||
Loading…
Add table
Add a link
Reference in a new issue