kings-guard/workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md

---
id: KG-WP-0004
type: workplan
title: "Sweep layer vocabulary through NetKingdomImmuneArchitecture.md"
domain: infotech
repo: kings-guard
status: active
owner: kings-guard
topic_slug: netkingdom
created: "2026-09-02"
updated: "2026-09-02"
inventory: history/2026-09-02-architecture-layer-vocabulary-inventory.md
origin: residual
origin_ref: KG-IN-0002
promoted_from: KG-IN-0002
source_decision: KG-DEC-2026-001
standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
state_hub_workstream_id: "104d4cfb-d945-56e4-996e-3d319334f949"
---

# Sweep layer vocabulary through NetKingdomImmuneArchitecture.md

`specs/NetKingdomImmuneArchitecture.md` predates the NetKingdom Security
Layer Model. A scoping note (2026-08-28, still citing v0.6) heads the file
so no reading takes "control plane" as a kings-guard self-description, but
the body is unadapted. This is G9 of
`history/2026-08-29-layer-model-v0.7-scope-intent-review.md`. Promoted from
intake `KG-IN-0002`, itself a residual of `KG-DEC-2026-001`.

Two things are being fixed, and they are the same defect read twice:

- **"Control plane" is Engine-layer vocabulary (§8).** The document uses it
  for an estate-wide arrangement that mixes identity, decision, response,
  memory, and audit. Some uses are legitimate (a Kubernetes control plane, a
  sovereign tenant's own operations plane). Those stay, labelled. Uses that
  describe kings-guard, or that collapse Staff judgment into an Engine
  plane, do not.
- **§9.2 moved containment off this repository.** Phase 5 still reads as
  if selected incidents "can be contained automatically" from this
  architecture. kings-guard proposes; an Engine renders; a PEP acts. The
  actuation surface is unowned estate-wide.

## Boundaries this workplan does not cross

- **No code change is required.** The scaffold already matches INTENT/SCOPE
  under v0.7. This is a document sweep of one spec.
- **No actuation, no Tooling contact, no engine gap worked around.**
- **Do not invent a second architecture.** The immune planes stay; they are
  re-homed onto Staff / Engine / Tooling rather than rewritten as a new
  model.
- **Do not delete every occurrence of "control plane".** Kubernetes control
  planes, tenant-sovereign operations planes, and similar Engine/platform
  uses are disambiguated, not erased.

## Known mismatches at promotion

Inventory at 2026-09-02, against v0.7. T01 re-derives this rather than
trusting the list as closed.

| Location | What is wrong |
| --- | --- |
| Head layer note | Cites v0.6; still points at this intake. |
| §2 | "recursive adaptive security control system" — control-system is the same overlap as control plane. |
| §3.1 | In-scope list includes "local and global security decisions" and "automated … response" as if this architecture owns them. |
| §8 diagram | Subgraph `Platform Immune Control Plane` holds identity, decision, response regulation, memory, audit, and signal together. |
| §9.6 Decision Plane | `immune_decision` with `authorized_response` is an Engine decision record, written as if it were this architecture's output. §6: one decision point, `access-engine`. |
| §9.7 Response Plane | "executes defensive actions" — actuation. Staff proposes; Engine/PEP execute. |
| §16 authority grant | `kg:authority:tenant-isolator` granted to a "tenant-immune-node" that isolates. Isolation is Engine/PEP. |
| §25.2 Effector Contract | `decision_ref` then `action: isolate` with no origin observation/signal and no authority-boundary. WP-0003-T06 already fixed the scaffold. |
| §31 Phase 5 | Success = "contained automatically". Stage 3 in INTENT.md is "proposals are well-formed and reconstructable, not when anything is contained". |
| Remaining "control plane" strings | §9.4 control-plane sentinel; §10.2 cluster and control-plane security; §11 I3 sovereign control plane; §26.3 dedicated tenant control plane. Likely Engine/k8s uses — confirm and label. |

## Dependency order

```text
T01 inventory
  -> T02 re-home planes and the §8 diagram
    -> T03 remaining "control plane" strings
    -> T04 containment / Phase 5 / effector contract
      -> T05 §6 audit, layer note, version
```

## Task: Inventory every layer mismatch in the architecture spec

```task
id: KG-WP-0004-T01
status: done
priority: high
state_hub_task_id: "a4feb6c0-7969-5786-9a11-cb9130a625ea"
```

Re-read `specs/NetKingdomImmuneArchitecture.md` against
`net-kingdom/canon/standards/security-layer-model_v0.7.md` §§3.4, 5, 6, 8,
9.2. Produce a section-by-section map: Staff (observe, judge, propose),
Engine (decide, act), Tooling (hold, attest, store), or legitimate
platform/k8s wording that stays.

Done when:

- the map lives in `history/` (or as a table in this workplan) and names
  every "control plane" occurrence, every decision/response plane claim,
  and every place that implies kings-guard actuates;
- each row says keep / re-home / rewrite;
- T02–T04 can be executed from the map without re-discovering the file.

**Done 2026-09-02:** Map is
`history/2026-09-02-architecture-layer-vocabulary-inventory.md`. It names
every `control plane` occurrence (six hits; four are keep-label k8s/platform),
every decision/response-plane claim, and every actuation implication, each
with keep / keep-label / re-home / rewrite. Section-by-section table covers
frontmatter through §36. T02–T04 slices are listed in §4 of that file.

## Task: Re-home the §8 diagram and the nine planes onto Staff / Engine / Tooling

```task
id: KG-WP-0004-T02
status: done
priority: high
state_hub_task_id: "2f7b3303-d87c-5c29-9249-98afd746631f"
```

The `Platform Immune Control Plane` subgraph is the load-bearing error.
Split it so a reader can see which boxes are Engine authorities (identity
issuance, decision, actuation) and which are kings-guard's
observation-and-judgment surface (genome consumption, phenotype, posture,
signals, proposals, governed memory that is not a state plane).

§9.6 Decision Plane becomes the Engine decision point (`access-engine`),
not a Staff output. §9.7 Response Plane becomes Engine + PEP. Genome,
sentinel/evidence, signal, and memory stay readable as Staff-owned or
shared contracts, not as a second PDP.

Done when:

- the §8 diagram no longer names a kings-guard control plane;
- each of the nine planes states its layer;
- `immune_decision` is explicitly an Engine artifact, not a kings-guard
  posture record.

**Done 2026-09-02:** §8 subgraph is Staff (observe/judge/propose) vs Engine
(PDP, facts, evidence, unowned actuation) — no kings-guard control plane.
Each of the nine planes states its layer. `immune_decision` is labelled an
`access-engine` artifact. Observation no longer carries assessment/proposed
response. Related T02 slices: §2 cycle, §3.1 estate-vs-repo, §5 analogy,
§10 node, §15 VSM, §17 posture publisher, §19 data model, §20.2, §22.2,
§24 `immune-judgment/`, §25.1, §27 decision hops, §31 Phase 4. T03/T04
strings and actuation copy left in place.

## Task: Disambiguate remaining "control plane" strings

```task
id: KG-WP-0004-T03
status: done
priority: medium
state_hub_task_id: "4e97c257-9819-51fc-900b-d632992d096d"
```

The leftover strings are probably not about kings-guard. Confirm and label
them so a later reader does not have to guess:

- §9.4 "control-plane sentinel"
- §10.2 "cluster and control-plane security"
- §11 I3 "Dedicated account, keys, control plane and operations"
- §26.3 "dedicated tenant control plane"

Done when:

- every remaining "control plane" occurrence is either gone or clearly an
  Engine/platform/Kubernetes plane;
- a grep for `control plane` / `control-plane` / `Control Plane` in the
  spec has no unlabeled hit.

**Done 2026-09-02:** Remaining hits are all labelled as Kubernetes/platform
API planes, or as the Staff denial "not an Engine-layer control plane".
I2 "control and compute plane" and management-plane near-misses labelled
the same way. Head note still cites v0.6 / KG-IN-0002 — that rewrite is T05.

## Task: Correct containment, Phase 5, and the effector contract

```task
id: KG-WP-0004-T04
status: todo
priority: high
state_hub_task_id: "bbb4c1aa-2808-5fde-8f9b-7fb7730f13c7"
```

Statute §9.2: kings-guard proposes containment and never performs it.
INTENT.md stage 3 is complete when proposals are well-formed and
reconstructable, not when anything is contained. Phase 5's success
condition ("contained automatically") is the pre-v0.6 charter.

Align:

- §9.7 response ladder — proposal vs execution;
- §16 authority grant — a Staff node does not receive isolate/revoke as
  a power it exercises;
- §25.2 effector contract — origin observation/signal, explicit
  `authority_boundary`, no widened authority (matches WP-0003-T06);
- §31 Phase 5 — bounded *proposal*, actuation unowned.

Done when:

- no sentence in the spec claims kings-guard contains, isolates, or
  otherwise actuates;
- Phase 5 cannot be read as "kings-guard will automatically contain";
- the effector example is a proposal, reconstructable to its origin.

## Task: Prove no Staff decision point; refresh the layer note

```task
id: KG-WP-0004-T05
status: todo
priority: medium
state_hub_task_id: "e56c68ee-0b52-51ad-9fef-b3e4e0f22ffa"
```

Statute §6: one decision point, `access-engine`. After T02–T04, walk the
file and confirm no Staff component renders or caches an allow/deny.
Update the head layer note from v0.6 to v0.7, drop the "tracked as
KG-IN-0002" pointer, bump the document version, and record the sweep date.

Done when:

- a short audit (in the workplan or `history/`) lists candidate
  decision-shaped objects and where each now lives;
- the layer note matches `INTENT.md` (Staff, v0.7, proposes containment,
  does not own it);
- `git diff --check` is clean.

## Success criteria

1. Every task above is `done`.
2. `grep -nE 'control plane|control-plane|Control Plane' specs/NetKingdomImmuneArchitecture.md` has only labelled Engine/platform/k8s hits, or none.
3. The spec cannot be read as placing a decision point or an actuator in Staff.
4. `INTENT.md`, `SCOPE.md`, and this spec agree on layer, containment, and memory-as-not-a-state-plane.
5. `make test` and `make check-layer` still pass (no code change expected).