# 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`. |
| §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