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

Complete KG-WP-0004-T02: re-home architecture planes onto Staff and Engine

Browse source 
Split the former Platform Immune Control Plane so kings-guard observes,
judges, and proposes while access-engine remains the only decision point.
Each of the nine planes now states its layer. immune_decision is an Engine
artifact, not a posture record.

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

2
WORK-RECORDS.md
View file

@ -28,7 +28,7 @@
| task | KG-WP-0003-T07 | done | — | workplans/KG-WP-0003-evidence-completeness-and-live-observation.md | | task | KG-WP-0003-T07 | done | — | workplans/KG-WP-0003-evidence-completeness-and-live-observation.md |
| task | KG-WP-0003-T08 | done | — | workplans/KG-WP-0003-evidence-completeness-and-live-observation.md | | task | KG-WP-0003-T08 | done | — | workplans/KG-WP-0003-evidence-completeness-and-live-observation.md |
| task | KG-WP-0004-T01 | done | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md | | task | KG-WP-0004-T01 | done | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
| task | KG-WP-0004-T02 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md | | task | KG-WP-0004-T02 | done | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
| task | KG-WP-0004-T03 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md | | task | KG-WP-0004-T03 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
| task | KG-WP-0004-T04 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md | | task | KG-WP-0004-T04 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
| task | KG-WP-0004-T05 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md | | task | KG-WP-0004-T05 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |

378
specs/NetKingdomImmuneArchitecture.md
View file

@ -53,20 +53,24 @@ The architecture aims to preserve the platform's viability by enabling it to:
## 2. Architectural Proposition ## 2. Architectural Proposition
Kings Guard Security is a **recursive adaptive security control system**. 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.
It continuously executes the following cycle: The estate cycle, with layer:
```text ```text
declare healthy intent declare healthy intent # owners; Staff consumes the genome
→ establish and attest identity → establish and attest identity # Tooling (key-cape) / Engine (user-engine)
→ observe actual behaviour → observe actual behaviour # Staff (kings-guard)
→ compare behaviour with intent and policy → compare behaviour with intent # Staff
→ assess risk and confidence → assess risk and confidence (posture) # Staff publishes; gate-house defines meaning
→ respond within bounded authority → propose bounded response # Staff — never manufactures authority
→ restore known-good operation → decide # Engine (access-engine), the only PDP
→ actuate # Engine + PEP; surface unowned, held at zero
→ restore known-good operation # Engine / runtime
→ validate the outcome → validate the outcome
→ retain governed security memory → retain governed security memory # Staff; not a state plane for other layers
``` ```
The system does not treat trust as a permanent property. The system does not treat trust as a permanent property.
@ -90,25 +94,29 @@ Trust is a temporary, scoped and continuously reassessed condition derived from:
### 3.1 In Scope ### 3.1 In Scope
This architecture covers: This document is an **estate map**. It names Staff, Engine, PEP, and Tooling
parts of the immune loop so they are not collapsed into `kings-guard`.
- human, device, workload, service and agent identities; The `kings-guard` **repository** owns observation, judgment, posture
- authentication, authorization and continuous trust evaluation; publication, bounded proposals, and governed immune memory. It does not own
- tenant compartmentation; identity issuance, authorization decisions, secret custody, or actuation.
- workload isolation;
- network and data boundaries; The estate map also covers, in other layers:
- policy distribution and enforcement;
- admission control; - human, device, workload, service and agent identities (Tooling / Engine);
- runtime detection; - authentication, authorization and continuous trust evaluation (Engine PDP);
- security event transport; - tenant compartmentation, workload isolation, network and data boundaries
- local and global security decisions; (Engine / PEP / runtime);
- automated and human-approved response; - policy distribution and enforcement (Engine / PEP);
- recovery and reconstitution; - admission control (Engine / PEP);
- incident evidence; - runtime detection and security event transport (PEP / Staff observation);
- adaptive security memory; - the single authorization decision point (Engine: `access-engine`);
- cross-tenant defensive learning; - automated and human-approved response (Engine + PEP; actuation unowned);
- security governance and safety controls; - recovery and reconstitution (Engine / runtime);
- security observability and assurance. - incident evidence custody (Engine: `audit-core`);
- adaptive security memory (Staff; not a state plane);
- cross-tenant defensive learning (Staff publication);
- security governance, observability and assurance.
### 3.2 Out of Scope ### 3.2 Out of Scope
@ -233,6 +241,9 @@ Examples:
Governed knowledge derived from observations, incidents, threat intelligence, countermeasures and response outcomes. Governed knowledge derived from observations, incidents, threat intelligence, countermeasures and response outcomes.
**Layer: Staff.** Memory is not a state plane. Other layers must not depend
on it at runtime unless it is catalogued as Tooling.
### 4.11 Tolerance ### 4.11 Tolerance
The explicit permission for a known deviation, exception or variation that must not trigger an inappropriate defensive response. The explicit permission for a known deviation, exception or variation that must not trigger an inappropriate defensive response.
@ -260,10 +271,10 @@ The replacement of a compromised or uncertain component with a newly established
| Pattern-recognition receptors | Detection mechanisms | Sensor and Observation Mesh | | Pattern-recognition receptors | Detection mechanisms | Sensor and Observation Mesh |
| Antigen presentation | Contextualized evidence | Evidence Normalization | | Antigen presentation | Contextualized evidence | Evidence Normalization |
| Cytokines | Distributed coordination signals | Immune Signal Fabric | | Cytokines | Distributed coordination signals | Immune Signal Fabric |
| Lymph nodes | Local correlation and decision | Tenant Immune Node | | Lymph nodes | Local correlation and judgment | Tenant posture / immune node (Staff) |
| Adaptive immunity | Incident-specific learning | Adaptive Decision and Policy Generation | | Adaptive immunity | Incident-specific learning | Posture, proposals, and governed memory (Staff) |
| Antibodies | Targeted countermeasures | Signatures, Rules and Revocations | | Antibodies | Targeted countermeasures | Policy rules rendered by the PDP; Staff may propose |
| Complement system | Immediate action primitives | Response Effectors | | Complement system | Immediate action primitives | Response effectors (PEP-shaped; not Staff) |
| Memory cells | Retained defensive knowledge | Immune Memory | | Memory cells | Retained defensive knowledge | Immune Memory |
| Regulatory T cells | Safety and restraint | Immune Regulation | | Regulatory T cells | Safety and restraint | Immune Regulation |
| Inflammation | Elevated defensive state | Defensive Posture Management | | Inflammation | Elevated defensive state | Defensive Posture Management |
@ -433,13 +444,18 @@ flowchart TB
RISK["Risk Profiles and Security Objectives"] RISK["Risk Profiles and Security Objectives"]
end end
subgraph CONTROL["Platform Immune Control Plane"] subgraph STAFF["Staff — observe, judge, propose"]
IDENTITY["Identity and Attestation Authority"] JUDGE["Posture and Phenotype Judgment"]
DECISION["Decision and Response Engine"]
REGULATION["Safety, Tolerance and Escalation Controller"]
MEMORY["Immune Memory and Countermeasure Graph"]
AUDIT["Independent Audit and Validation"]
SIGNAL["Immune Signal Fabric"] SIGNAL["Immune Signal Fabric"]
MEMORY["Governed Immune Memory"]
PROPOSE["Bounded Response Proposals"]
end
subgraph ENGINE["Engine — facts, evidence, the only decision"]
IDENTITY["Identity facts — user-engine / key-cape"]
DECISION["access-engine — the only PDP"]
AUDIT["audit-core — evidence custody"]
ACTUATE["Actuation surface — unowned, held at zero"]
end end
subgraph TENANT["Tenant Immune Compartment"] subgraph TENANT["Tenant Immune Compartment"]
@ -447,22 +463,23 @@ flowchart TB
EDUCATION["Admission and Deployment Education"] EDUCATION["Admission and Deployment Education"]
APPLICATIONS["Applications, Data and Workloads"] APPLICATIONS["Applications, Data and Workloads"]
SENTINELS["Tenant Sentinels"] SENTINELS["Tenant Sentinels"]
NODE["Tenant Immune Node"] NODE["Tenant Immune Node — Staff judgment"]
EFFECTORS["Tenant Response Effectors"] EFFECTORS["Tenant Response Effectors — PEP"]
RECOVERY["Tenant Recovery and Reconstitution"] RECOVERY["Tenant Recovery — Engine / runtime"]
end end
subgraph SHARED["Shared Platform Compartments"] subgraph SHARED["Shared Platform Compartments"]
BROKER["Brokered Shared Services"] BROKER["Brokered Shared Services"]
INFRA["Compute, Network, Storage and Runtime"] INFRA["Compute, Network, Storage and Runtime"]
PSENTINELS["Platform Sentinels"] PSENTINELS["Platform Sentinels"]
PEFFECTORS["Platform Effectors"] PEFFECTORS["Platform Effectors — PEP"]
end end
EXT --> MEMBRANE EXT --> MEMBRANE
MEMBRANE --> APPLICATIONS MEMBRANE --> APPLICATIONS
GENOME --> IDENTITY GENOME --> IDENTITY
GENOME --> JUDGE
GENOME --> DECISION GENOME --> DECISION
GENOME --> EDUCATION GENOME --> EDUCATION
@ -474,16 +491,21 @@ flowchart TB
INFRA --> PSENTINELS INFRA --> PSENTINELS
SENTINELS --> NODE SENTINELS --> NODE
NODE --> JUDGE
NODE --> SIGNAL NODE --> SIGNAL
PSENTINELS --> SIGNAL PSENTINELS --> SIGNAL
SIGNAL --> JUDGE
JUDGE --> PROPOSE
JUDGE --> MEMORY
PROPOSE --> DECISION
SIGNAL --> DECISION SIGNAL --> DECISION
MEMORY --> DECISION RISK --> DECISION
RISK --> REGULATION MEMORY --> JUDGE
DECISION --> REGULATION
REGULATION --> EFFECTORS DECISION --> ACTUATE
REGULATION --> PEFFECTORS ACTUATE --> EFFECTORS
ACTUATE --> PEFFECTORS
EFFECTORS --> APPLICATIONS EFFECTORS --> APPLICATIONS
EFFECTORS --> MEMBRANE EFFECTORS --> MEMBRANE
@ -492,20 +514,45 @@ flowchart TB
RECOVERY --> APPLICATIONS RECOVERY --> APPLICATIONS
SIGNAL --> MEMORY SIGNAL --> MEMORY
AUDIT --> MEMORY
AUDIT --> DECISION AUDIT --> DECISION
APPLICATIONS <--> BROKER APPLICATIONS <--> BROKER
``` ```
Staff memory informs kings-guard's own later judgment and may be published as
evidence. It is not a runtime input to `access-engine` or to a PEP (§3.4 rule 3).
Actuation is drawn because the loop requires it; the surface is unowned and
held at zero (§9.2). No argument may assume isolation happens automatically.
---
--- ---
## 9. Architectural Planes ## 9. Architectural Planes
The architecture is organized into nine orthogonal planes. The architecture is organized into nine orthogonal planes. Each plane states
its layer. Staff planes observe, judge, and propose. Engine planes decide,
hold facts, or custody evidence. Tooling holds identity and secrets. PEP is
a shape, not a plane: anything that causes a protected side effect. Actuation
is an Engine concept held at zero (§9.2).
| Plane | Layer |
| --- | --- |
| 9.1 Security Genome | Staff consumes; owners produce |
| 9.2 Identity and Attestation | Tooling (`key-cape`) + Engine (`user-engine`) |
| 9.3 Membrane and Compartment | Engine / PEP / runtime |
| 9.4 Sentinel and Evidence | Staff observes Staff-reachable sources; many sentinels are PEP/runtime |
| 9.5 Signal and Coordination | Staff |
| 9.6 Decision | Engine (`access-engine`) — the only PDP |
| 9.7 Response | Engine + PEP; actuation unowned |
| 9.8 Recovery | Engine / runtime |
| 9.9 Memory and Adaptation | Staff; not a state plane |
### 9.1 Security Genome Plane ### 9.1 Security Genome Plane
**Layer: Staff consumes; workload and service owners produce.** kings-guard
does not run the intent registry.
The Security Genome Plane defines intended healthy operation. The Security Genome Plane defines intended healthy operation.
#### Responsibilities #### Responsibilities
@ -587,6 +634,10 @@ security_genome_record:
### 9.2 Identity and Attestation Plane ### 9.2 Identity and Attestation Plane
**Layer: Tooling (`key-cape`) + Engine (`user-engine`).** Issuance is not
Staff. Trust-posture *publication* is Staff; a lifetime other layers consume
is an input claim to the PDP, not a Staff verdict.
This plane establishes and reassesses subject identity. This plane establishes and reassesses subject identity.
#### Identity Classes #### Identity Classes
@ -637,6 +688,9 @@ trust_posture:
### 9.3 Membrane and Compartment Plane ### 9.3 Membrane and Compartment Plane
**Layer: Engine / PEP / runtime.** Policy enforcement at a membrane is
PEP-shaped. kings-guard does not hold the boundary.
This plane establishes nested boundaries. This plane establishes nested boundaries.
#### Membrane Types #### Membrane Types
@ -665,7 +719,14 @@ This plane establishes nested boundaries.
### 9.4 Sentinel and Evidence Plane ### 9.4 Sentinel and Evidence Plane
Sentinels observe security-relevant behaviour. **Layer: Staff observes Staff-reachable sources.** Many sentinels run in
PEP/runtime. Identity and secret observation stay pending (blocked-clean):
no Tooling client is opened to fill them. A "control-plane sentinel" watches
a Kubernetes or platform control plane; it does not make kings-guard one.
Sentinels observe security-relevant behaviour. An observation is not an
interpretation: assessment and proposed response belong on phenotype,
posture, and signal, not on this record.
#### Sentinel Classes #### Sentinel Classes
@ -715,21 +776,16 @@ immune_observation:
intent_relation: intent_relation:
expected: false expected: false
classification: prohibited classification: prohibited
assessment:
confidence: 0.97
severity: high
novelty: known
potential_blast_radius: application
proposed_response:
action: isolate
scope: workload
ttl: PT15M
``` ```
Phenotype, posture, and a bounded `effector_request` are derived later.
They are not fields of the observation.
### 9.5 Signal and Coordination Plane ### 9.5 Signal and Coordination Plane
**Layer: Staff.** Signals coordinate judgment and proposals. They are not
authorization.
The Immune Signal Fabric transports authenticated security messages. The Immune Signal Fabric transports authenticated security messages.
#### Signal Types #### Signal Types
@ -739,15 +795,17 @@ The Immune Signal Fabric transports authenticated security messages.
- policy violation; - policy violation;
- integrity failure; - integrity failure;
- attack hypothesis; - attack hypothesis;
- response request; - response request (Staff proposal);
- response authorization; - action result (PEP / Engine, when actuation exists);
- action result;
- recovery status; - recovery status;
- escalation; - escalation;
- countermeasure publication; - countermeasure publication;
- memory update; - memory update;
- audit challenge. - audit challenge.
Authorization is not a signal type. The PDP renders a decision record. A
Staff signal may *request* a restrictive direction; it must not authorize.
#### Signal Properties #### Signal Properties
Every signal must carry: Every signal must carry:
@ -780,7 +838,16 @@ Raw tenant evidence must not be elevated to platform or federation scope without
### 9.6 Decision Plane ### 9.6 Decision Plane
The Decision Plane evaluates observations and determines response. **Layer: Engine (`access-engine`).** This is the estate's only policy
decision point (layer model §6). It is not a kings-guard output. Posture
is an input claim; it is not a verdict.
The Decision Plane renders authorization from authoritative inputs. Staff
does not determine response here.
`immune_decision` below is an **Engine artifact** — the `access-engine`
decision record — not a posture assessment. A Staff node is not the
`authority` that isolates.
#### Decision Inputs #### Decision Inputs
@ -800,41 +867,45 @@ The Decision Plane evaluates observations and determines response.
#### Decision Output #### Decision Output
```yaml ```yaml
# Engine artifact (access-engine). Not a kings-guard posture record.
immune_decision: immune_decision:
decision_id: uuid decision_id: uuid
decided_at: 2026-07-23T18:00:02Z decided_at: 2026-07-23T18:00:02Z
pdp: access-engine
scope: scope:
tenant_id: tenant-a tenant_id: tenant-a
compartment_id: app-documents compartment_id: app-documents
hypothesis: inputs:
type: compromised-workload posture_ref: kg:posture:…
confidence: 0.91 genome_ref: kg:genome:…
evidence_refs:
- evidence://event/9876
authorized_response: authorized_response:
action: isolate action: isolate
target: spiffe://tenant-a.example/workload/document-converter target: spiffe://tenant-a.example/workload/document-converter
ttl: PT15M ttl: PT15M
authority: tenant-immune-node authority: access-engine
enforcement: pep
# Actuation surface unowned and held at zero (§9.2). This field is the
# intended Engine output, not a claim that isolation already happens.
rollback: automatic rollback: automatic
required_follow_up:
- collect-memory-image
- rotate-workload-credentials
- reconstitute-workload
- validate-service-health
explanation: explanation:
policy_refs: policy_refs:
- kg:policy:no-external-egress - kg:policy:no-external-egress
evidence_refs:
- evidence://event/9876
``` ```
### 9.7 Response Plane ### 9.7 Response Plane
The Response Plane executes defensive actions. **Layer: Engine + PEP. Actuation is unowned and held at zero (§9.2).**
kings-guard proposes the rungs; it does not execute them. Execution, safety
envelope, and the isolate grant are T04 of KG-WP-0004.
The Response Plane is where defensive *actions* would be performed, once an
actuation surface exists.
#### Response Ladder #### Response Ladder
@ -868,6 +939,9 @@ Every automated action requires:
### 9.8 Recovery and Reconstitution Plane ### 9.8 Recovery and Reconstitution Plane
**Layer: Engine / runtime.** Staff may request reconstitution. It does not
redeploy, rotate, or evacuate.
Recovery is an architectural peer of detection and response. Recovery is an architectural peer of detection and response.
#### Recovery Capabilities #### Recovery Capabilities
@ -902,6 +976,11 @@ A component must not return directly from `isolated` to `healthy` without valida
### 9.9 Memory and Adaptation Plane ### 9.9 Memory and Adaptation Plane
**Layer: Staff.** Immune memory informs kings-guard's own later judgment and
may be published as evidence. No engine, PEP, or workload may read it as a
runtime input. Making it one is a §4 Tooling catalog change, not a quiet
edge from this plane into §9.6.
The Memory Plane retains and evaluates security knowledge. The Memory Plane retains and evaluates security knowledge.
#### Memory Objects #### Memory Objects
@ -971,10 +1050,10 @@ flowchart TB
TW["Tenant Workloads"] TW["Tenant Workloads"]
TD["Tenant Data Domains"] TD["Tenant Data Domains"]
TS["Tenant Sentinel Mesh"] TS["Tenant Sentinel Mesh"]
TN["Tenant Immune Node"] TN["Tenant Immune Node — Staff"]
TR["Tenant Response Effectors"] TR["Tenant Response Effectors — PEP"]
TMEM["Tenant Immune Memory"] TMEM["Tenant Immune Memory — Staff"]
TREC["Tenant Recovery Controller"] TREC["Tenant Recovery Controller — Engine"]
TM --> TW TM --> TW
TI --> TM TI --> TM
@ -995,19 +1074,27 @@ flowchart TB
end end
``` ```
The Staff node judges and proposes. Effectors fire only on a decision
record from `access-engine`, or on a recorded PEP stance (§6.4). The arrow
`TN --> TR` is coordination, not a second PDP.
### 10.1 Tenant-Local Responsibilities ### 10.1 Tenant-Local Responsibilities
The tenant immune system owns: The tenant immune **Staff** surface owns:
- tenant-specific security intent; - tenant-specific security intent (genome consumption);
- application and data policies;
- tenant identities and delegated roles;
- tenant-specific anomaly baselines; - tenant-specific anomaly baselines;
- local incident correlation; - local incident correlation and judgment;
- local response decisions; - bounded response *proposals*;
- tenant-private evidence; - tenant-private evidence references;
- tenant-specific countermeasures; - tenant-specific countermeasures as published memory.
- tenant recovery procedures.
It does not own local response *decisions*. Those remain the one PDP.
A local PEP applying a prior decision, or a declared stance, is §6.4 — not
a second decision point.
Tenant identities, application policy administration, and recovery
procedures belong to Engine / Tooling / runtime, not to the Staff node.
### 10.2 Platform Responsibilities ### 10.2 Platform Responsibilities
@ -1228,12 +1315,12 @@ Target latency: days to quarters.
| VSM function | Kings Guard responsibility | | VSM function | Kings Guard responsibility |
|---|---| |---|---|
| System 1 — Operations | Workload, application and tenant sentinels and effectors | | System 1 — Operations | Workload, application and tenant sentinels (observe) and PEP-shaped effectors (act, when actuation exists) |
| System 2 — Coordination | Signal routing, deduplication, suppression and incident coordination | | System 2 — Coordination | Signal routing, deduplication, suppression and incident coordination (Staff) |
| System 3 — Control | Tenant and platform response controllers | | System 3 — Control | `access-engine` as PDP; PEP stance maps; not a Staff response controller |
| System 3* — Audit | Independent validation, forensic inspection and adversarial testing | | System 3* — Audit | Independent validation, forensic inspection and adversarial testing (`audit-core`, whitehat-security) |
| System 4 — Intelligence | Threat research, simulation, adaptive policies and immune memory | | System 4 — Intelligence | Threat research, simulation, and governed immune memory (Staff; not a state plane) |
| System 5 — Policy | Security identity, principles, risk appetite and response authority | | System 5 — Policy | Doctrine (gate-house) compiled into the versioned policy package the PDP applies |
The same mapping applies recursively to: The same mapping applies recursively to:
@ -1304,6 +1391,15 @@ response_authority:
## 17. Defensive Posture Model ## 17. Defensive Posture Model
**Layer: Staff publishes; gate-house defines authority meaning;
`access-engine` renders.** Posture is not a privilege source. It may reduce
authority, require step-up, or request containment; it MUST NOT
probabilistically manufacture additional authority.
The executable scaffold uses `healthy`, `elevated`, `inflamed`,
`compromised`. The colours below are a reading aid, not a second grading
scale and not a second decision point.
The system maintains explicit defensive posture. The system maintains explicit defensive posture.
| Posture | Meaning | Typical controls | | Posture | Meaning | Typical controls |
@ -1469,7 +1565,9 @@ erDiagram
SUBJECT ||--o{ OBSERVATION : produces SUBJECT ||--o{ OBSERVATION : produces
RESOURCE ||--o{ OBSERVATION : concerns RESOURCE ||--o{ OBSERVATION : concerns
OBSERVATION }o--o{ EVIDENCE : references OBSERVATION }o--o{ EVIDENCE : references
OBSERVATION ||--o{ DECISION : informs OBSERVATION ||--o{ POSTURE : informs
POSTURE ||--o{ SIGNAL : emits
SIGNAL ||--o{ DECISION : inputs
DECISION ||--o{ RESPONSE_ACTION : authorizes DECISION ||--o{ RESPONSE_ACTION : authorizes
RESPONSE_ACTION ||--o{ RESPONSE_OUTCOME : produces RESPONSE_ACTION ||--o{ RESPONSE_OUTCOME : produces
RESPONSE_OUTCOME ||--o{ MEMORY_OBJECT : informs RESPONSE_OUTCOME ||--o{ MEMORY_OBJECT : informs
@ -1485,14 +1583,18 @@ The data model must preserve separation among:
- raw evidence; - raw evidence;
- normalized observation; - normalized observation;
- phenotype and posture (Staff judgment);
- attack hypothesis; - attack hypothesis;
- decision; - decision (`access-engine` only);
- response authorization; - response authorization (the same decision record);
- action execution; - action execution (PEP / actuation surface, unowned today);
- outcome; - outcome;
- lesson; - lesson;
- policy change. - policy change.
Immune memory may be derived from outcome and lesson. It MUST NOT appear as
an input arrow into DECISION.
--- ---
## 20. Policy Architecture ## 20. Policy Architecture
@ -1526,13 +1628,14 @@ Policies are layered.
A lower layer may strengthen a higher-layer requirement but may weaken it only through an authorized exception. A lower layer may strengthen a higher-layer requirement but may weaken it only through an authorized exception.
Policy decisions must expose: **Policy decisions are rendered by `access-engine`.** Reconstructability is
a PDP obligation, not a Staff API. A decision record must expose:
- effective policies; - effective policies;
- precedence; - precedence;
- exceptions; - exceptions;
- reason; - reason;
- decision inputs; - decision inputs (including posture as a claim, not as a verdict);
- resulting constraints. - resulting constraints.
--- ---
@ -1584,8 +1687,9 @@ Security observability includes both threat state and immune-system health.
- sentinel coverage; - sentinel coverage;
- signal delivery latency; - signal delivery latency;
- decision latency; - judgment latency (Staff);
- response latency; - decision latency (PDP);
- response latency (PEP / actuation, when the surface exists);
- failed effectors; - failed effectors;
- stale trust posture; - stale trust posture;
- policy distribution lag; - policy distribution lag;
@ -1708,22 +1812,22 @@ kings-guard/
│ │
├── immune-coordination/ ├── immune-coordination/
│ ├── signal-fabric/ │ ├── signal-fabric/
│ ├── tenant-immune-node/ │ ├── tenant-immune-node/ # Staff judgment, not a PDP
│ ├── platform-immune-node/ │ ├── platform-immune-node/
│ ├── federation/ │ ├── federation/
│ └── signal-schema/ │ └── signal-schema/
│ │
├── immune-decision/ ├── immune-judgment/ # Staff — not a second decision point
│ ├── policy-evaluation/ │ ├── phenotype/
│ ├── risk-evaluation/ │ ├── posture/
│ ├── attack-hypothesis/ │ ├── attack-hypothesis/
│ ├── response-selection/ │ ├── response-proposal/
│ └── decision-schema/ │ └── posture-schema/
│ │
├── immune-response/ ├── immune-response/ # Engine + PEP; not a kings-guard tree
│ ├── response-orchestrator/ │ ├── proposal-contract/ # Staff emits; see ImmuneContracts.md
│ ├── effectors/ │ ├── effectors/ # PEP-shaped; actuation unowned
│ ├── authority-control/ │ ├── authority-control/ # access-engine
│ ├── escalation/ │ ├── escalation/
│ └── response-schema/ │ └── response-schema/
│ │
@ -1772,9 +1876,9 @@ The architecture should stabilize contracts before selecting implementations.
- Security Genome Contract; - Security Genome Contract;
- Immune Observation Contract; - Immune Observation Contract;
- Immune Signal Contract; - Immune Signal Contract;
- Decision Contract; - Decision Contract (owned by `access-engine`; statute §17);
- Response Authority Contract; - Response Authority Contract;
- Effector Contract; - Effector Contract (Staff proposal shape; execution is PEP);
- Response Outcome Contract; - Response Outcome Contract;
- Recovery Contract; - Recovery Contract;
- Memory Object Contract; - Memory Object Contract;
@ -1917,29 +2021,27 @@ A tenant workload attempts an external connection that is not declared in its Se
```mermaid ```mermaid
sequenceDiagram sequenceDiagram
participant W as Workload participant W as Workload
participant S as Runtime Sentinel participant S as Runtime Sentinel (PEP-shaped)
participant N as Tenant Immune Node participant N as Tenant Immune Node (Staff)
participant D as Decision Engine participant D as access-engine (PDP)
participant R as Regulation Controller participant E as Network Effector (PEP)
participant E as Network Effector participant M as Immune Memory (Staff)
participant M as Immune Memory participant H as Recovery (Engine / runtime)
participant H as Recovery Controller
W->>S: Attempt prohibited external connection W->>S: Attempt prohibited external connection
S->>S: Block attempt using local rule S->>S: Block attempt under existing policy (local PEP)
S->>N: Publish observation and evidence S->>N: Publish observation and evidence
N->>D: Request contextual assessment N->>N: Derive phenotype and posture
D->>D: Compare identity, intent, posture and history N->>D: Publish posture as an input claim plus a containment proposal
D->>R: Propose temporary workload isolation D->>D: Render the only authorization decision
R->>R: Validate authority, blast radius and TTL D->>E: Decision record (actuation unowned today — intended hop)
R->>E: Authorize isolation E->>W: Isolate workload if and when actuation exists
E->>W: Isolate workload
E->>N: Return action outcome E->>N: Return action outcome
N->>H: Request credential rotation and reconstitution N->>H: Request credential rotation and reconstitution
H->>W: Replace with known-good workload H->>W: Replace with known-good workload
H->>N: Return validation result H->>N: Return validation result
N->>M: Store evidence, action and outcome N->>M: Store evidence, proposal, decision ref and outcome
M->>D: Update future decision context Note over M,D: Memory is not a runtime input to the PDP
``` ```
### Result ### Result
@ -2106,14 +2208,14 @@ Security-relevant behaviour is attributable, normalized and routed to the correc
Deliver: Deliver:
- tenant-local correlation; - tenant-local correlation;
- policy evaluation;
- trust posture integration; - trust posture integration;
- response recommendations; - response *recommendations* (proposals, not PDP evaluation);
- tenant-private memory. - tenant-private memory that is not a runtime input to other layers.
Success condition: Success condition:
Common tenant incidents can be assessed without central manual correlation. Common tenant incidents can be judged without central manual correlation.
Policy evaluation remains `access-engine`.
### Phase 5 — Bounded Automated Response ### Phase 5 — Bounded Automated Response
@ -2273,7 +2375,7 @@ The Kings Guard architecture is successful when the platform can demonstrate tha
## 36. Summary ## 36. Summary
Kings Guard Security implements the NetKingdom immune-security concept as a recursive, multi-tenant control architecture. Kings Guard Security implements the NetKingdom immune-security concept as a recursive, multi-tenant defence architecture. `kings-guard` observes, judges, and proposes. Engines decide. PEPs act, when an actuation surface exists.
Its defining sequence is: Its defining sequence is:

11
workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md
View file

@ -114,7 +114,7 @@ frontmatter through §36. T02–T04 slices are listed in §4 of that file.
```task ```task
id: KG-WP-0004-T02 id: KG-WP-0004-T02
status: todo status: done
priority: high priority: high
state_hub_task_id: "2f7b3303-d87c-5c29-9249-98afd746631f" state_hub_task_id: "2f7b3303-d87c-5c29-9249-98afd746631f"
``` ```
@ -137,6 +137,15 @@ Done when:
- `immune_decision` is explicitly an Engine artifact, not a kings-guard - `immune_decision` is explicitly an Engine artifact, not a kings-guard
posture record. 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: Disambiguate remaining "control plane" strings
```task ```task