coulomb/kings-guard
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Complete KG-WP-0004-T03: label remaining control-plane strings

Browse source 
Every leftover control-plane mention is now a Kubernetes or platform API
plane, or an explicit denial that kings-guard is not one. Head-note v0.7
refresh stays T05.

Assistant: grok
Assistant-Session: 01a05ef1-9e5a-70f2-b0ff-0b05d6b38ae9
This commit is contained in:
tegwick 2026-09-02 01:28:30 +02:00
parent 569def5584
commit 3493aac2ac
3 changed files with 17 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

19
specs/NetKingdomImmuneArchitecture.md
View file

@ -55,7 +55,8 @@ The architecture aims to preserve the platform's viability by enabling it to:
Kings Guard Security is a **recursive adaptive defence architecture**.
`kings-guard` is the Staff repository in that architecture: it observes,
judges, and proposes. It is not a control plane and not a decision point.
judges, and proposes. It is not an Engine-layer control plane and not a
decision point.
The estate cycle, with layer:
@ -159,7 +160,7 @@ Examples:
- namespace;
- application domain;
- data domain;
- management plane;
- platform management plane (Kubernetes/API operators; not Staff);
- sovereign environment.
### 4.3 Subject
@ -700,7 +701,7 @@ This plane establishes nested boundaries.
3. application membrane;
4. workload membrane;
5. data membrane;
6. management membrane;
6. management membrane (platform API/operator plane; not Staff);
7. supply-chain membrane.
#### Boundary Controls
@ -739,7 +740,7 @@ posture, and signal, not on this record.
- API sentinel;
- data-access sentinel;
- secret sentinel;
- control-plane sentinel;
- control-plane sentinel (observes the Kubernetes/platform API plane; does not make kings-guard a control plane);
- supply-chain sentinel;
- application-domain sentinel.
@ -1102,7 +1103,7 @@ The platform immune system owns:
- platform availability and integrity;
- shared infrastructure;
- cluster and control-plane security;
- cluster and Kubernetes-control-plane security (the platform API plane, not Staff);
- common identity and attestation services;
- baseline security controls;
- supply-chain controls;
@ -1138,8 +1139,8 @@ Different workloads require different strengths of isolation.
|---|---|---|
| I0 Shared | Logical isolation for low-risk workloads | Namespace, identity and policy boundaries |
| I1 Reinforced | Stronger runtime and node separation | Sandboxed runtime, dedicated node pools |
| I2 Dedicated | Tenant-specific control and compute plane | Dedicated cluster or virtual cluster |
| I3 Sovereign | Independent authority and infrastructure boundary | Dedicated account, keys, control plane and operations |
| I2 Dedicated | Tenant-specific Kubernetes control and compute planes (cluster API, not Staff) | Dedicated cluster or virtual cluster |
| I3 Sovereign | Independent authority and infrastructure boundary | Dedicated account, keys, cloud/Kubernetes control plane and operations (tenant's own Engine/platform plane, not kings-guard) |
| I4 Air-Gapped | Deliberately disconnected or highly mediated environment | Offline or broker-only exchange |
Isolation profile selection considers:
@ -1974,7 +1975,7 @@ Typical characteristics:
- dedicated cluster;
- dedicated keys;
- dedicated tenant control plane;
- dedicated tenant Kubernetes/cloud control plane (the tenant's platform API plane, not Staff);
- tenant-specific recovery environment;
- platform federation through signed defensive signals.
@ -2182,7 +2183,7 @@ Deliver:
- tenant isolation profiles;
- ingress and egress policy;
- shared-service brokerage;
- management-plane separation;
- platform management-plane separation (API/operator plane, not Staff);
- tenant-specific encryption and secret boundaries.
Success condition: