diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 30c9bc9..70d7b40 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -28,7 +28,7 @@ | 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-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-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 | diff --git a/specs/NetKingdomImmuneArchitecture.md b/specs/NetKingdomImmuneArchitecture.md index 7d01f0c..1a0fcdc 100755 --- a/specs/NetKingdomImmuneArchitecture.md +++ b/specs/NetKingdomImmuneArchitecture.md @@ -53,20 +53,24 @@ The architecture aims to preserve the platform's viability by enabling it to: ## 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 -declare healthy intent -→ establish and attest identity -→ observe actual behaviour -→ compare behaviour with intent and policy -→ assess risk and confidence -→ respond within bounded authority -→ restore known-good operation +declare healthy intent # owners; Staff consumes the genome +→ establish and attest identity # Tooling (key-cape) / Engine (user-engine) +→ observe actual behaviour # Staff (kings-guard) +→ compare behaviour with intent # Staff +→ assess risk and confidence (posture) # Staff publishes; gate-house defines meaning +→ propose bounded response # Staff — never manufactures authority +→ decide # Engine (access-engine), the only PDP +→ actuate # Engine + PEP; surface unowned, held at zero +→ restore known-good operation # Engine / runtime → 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. @@ -90,25 +94,29 @@ Trust is a temporary, scoped and continuously reassessed condition derived from: ### 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; -- authentication, authorization and continuous trust evaluation; -- tenant compartmentation; -- workload isolation; -- network and data boundaries; -- policy distribution and enforcement; -- admission control; -- runtime detection; -- security event transport; -- local and global security decisions; -- automated and human-approved response; -- recovery and reconstitution; -- incident evidence; -- adaptive security memory; -- cross-tenant defensive learning; -- security governance and safety controls; -- security observability and assurance. +The `kings-guard` **repository** owns observation, judgment, posture +publication, bounded proposals, and governed immune memory. It does not own +identity issuance, authorization decisions, secret custody, or actuation. + +The estate map also covers, in other layers: + +- human, device, workload, service and agent identities (Tooling / Engine); +- authentication, authorization and continuous trust evaluation (Engine PDP); +- tenant compartmentation, workload isolation, network and data boundaries + (Engine / PEP / runtime); +- policy distribution and enforcement (Engine / PEP); +- admission control (Engine / PEP); +- runtime detection and security event transport (PEP / Staff observation); +- the single authorization decision point (Engine: `access-engine`); +- automated and human-approved response (Engine + PEP; actuation unowned); +- recovery and reconstitution (Engine / runtime); +- 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 @@ -233,6 +241,9 @@ Examples: 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 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 | | Antigen presentation | Contextualized evidence | Evidence Normalization | | Cytokines | Distributed coordination signals | Immune Signal Fabric | -| Lymph nodes | Local correlation and decision | Tenant Immune Node | -| Adaptive immunity | Incident-specific learning | Adaptive Decision and Policy Generation | -| Antibodies | Targeted countermeasures | Signatures, Rules and Revocations | -| Complement system | Immediate action primitives | Response Effectors | +| Lymph nodes | Local correlation and judgment | Tenant posture / immune node (Staff) | +| Adaptive immunity | Incident-specific learning | Posture, proposals, and governed memory (Staff) | +| Antibodies | Targeted countermeasures | Policy rules rendered by the PDP; Staff may propose | +| Complement system | Immediate action primitives | Response effectors (PEP-shaped; not Staff) | | Memory cells | Retained defensive knowledge | Immune Memory | | Regulatory T cells | Safety and restraint | Immune Regulation | | Inflammation | Elevated defensive state | Defensive Posture Management | @@ -433,13 +444,18 @@ flowchart TB RISK["Risk Profiles and Security Objectives"] end - subgraph CONTROL["Platform Immune Control Plane"] - IDENTITY["Identity and Attestation Authority"] - DECISION["Decision and Response Engine"] - REGULATION["Safety, Tolerance and Escalation Controller"] - MEMORY["Immune Memory and Countermeasure Graph"] - AUDIT["Independent Audit and Validation"] + subgraph STAFF["Staff — observe, judge, propose"] + JUDGE["Posture and Phenotype Judgment"] 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 subgraph TENANT["Tenant Immune Compartment"] @@ -447,22 +463,23 @@ flowchart TB EDUCATION["Admission and Deployment Education"] APPLICATIONS["Applications, Data and Workloads"] SENTINELS["Tenant Sentinels"] - NODE["Tenant Immune Node"] - EFFECTORS["Tenant Response Effectors"] - RECOVERY["Tenant Recovery and Reconstitution"] + NODE["Tenant Immune Node — Staff judgment"] + EFFECTORS["Tenant Response Effectors — PEP"] + RECOVERY["Tenant Recovery — Engine / runtime"] end subgraph SHARED["Shared Platform Compartments"] BROKER["Brokered Shared Services"] INFRA["Compute, Network, Storage and Runtime"] PSENTINELS["Platform Sentinels"] - PEFFECTORS["Platform Effectors"] + PEFFECTORS["Platform Effectors — PEP"] end EXT --> MEMBRANE MEMBRANE --> APPLICATIONS GENOME --> IDENTITY + GENOME --> JUDGE GENOME --> DECISION GENOME --> EDUCATION @@ -474,16 +491,21 @@ flowchart TB INFRA --> PSENTINELS SENTINELS --> NODE + NODE --> JUDGE NODE --> SIGNAL PSENTINELS --> SIGNAL + SIGNAL --> JUDGE + JUDGE --> PROPOSE + JUDGE --> MEMORY + PROPOSE --> DECISION SIGNAL --> DECISION - MEMORY --> DECISION - RISK --> REGULATION - DECISION --> REGULATION + RISK --> DECISION + MEMORY --> JUDGE - REGULATION --> EFFECTORS - REGULATION --> PEFFECTORS + DECISION --> ACTUATE + ACTUATE --> EFFECTORS + ACTUATE --> PEFFECTORS EFFECTORS --> APPLICATIONS EFFECTORS --> MEMBRANE @@ -492,20 +514,45 @@ flowchart TB RECOVERY --> APPLICATIONS SIGNAL --> MEMORY - AUDIT --> MEMORY AUDIT --> DECISION 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 -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 +**Layer: Staff consumes; workload and service owners produce.** kings-guard +does not run the intent registry. + The Security Genome Plane defines intended healthy operation. #### Responsibilities @@ -587,6 +634,10 @@ security_genome_record: ### 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. #### Identity Classes @@ -637,6 +688,9 @@ trust_posture: ### 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. #### Membrane Types @@ -665,7 +719,14 @@ This plane establishes nested boundaries. ### 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 @@ -715,21 +776,16 @@ immune_observation: intent_relation: expected: false 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 +**Layer: Staff.** Signals coordinate judgment and proposals. They are not +authorization. + The Immune Signal Fabric transports authenticated security messages. #### Signal Types @@ -739,15 +795,17 @@ The Immune Signal Fabric transports authenticated security messages. - policy violation; - integrity failure; - attack hypothesis; -- response request; -- response authorization; -- action result; +- response request (Staff proposal); +- action result (PEP / Engine, when actuation exists); - recovery status; - escalation; - countermeasure publication; - memory update; - 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 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 -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 @@ -800,41 +867,45 @@ The Decision Plane evaluates observations and determines response. #### Decision Output ```yaml +# Engine artifact (access-engine). Not a kings-guard posture record. immune_decision: decision_id: uuid decided_at: 2026-07-23T18:00:02Z + pdp: access-engine scope: tenant_id: tenant-a compartment_id: app-documents - hypothesis: - type: compromised-workload - confidence: 0.91 + inputs: + posture_ref: kg:posture:… + genome_ref: kg:genome:… + evidence_refs: + - evidence://event/9876 authorized_response: action: isolate target: spiffe://tenant-a.example/workload/document-converter 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 - required_follow_up: - - collect-memory-image - - rotate-workload-credentials - - reconstitute-workload - - validate-service-health - explanation: policy_refs: - kg:policy:no-external-egress - evidence_refs: - - evidence://event/9876 ``` ### 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 @@ -868,6 +939,9 @@ Every automated action requires: ### 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 Capabilities @@ -902,6 +976,11 @@ A component must not return directly from `isolated` to `healthy` without valida ### 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. #### Memory Objects @@ -971,10 +1050,10 @@ flowchart TB TW["Tenant Workloads"] TD["Tenant Data Domains"] TS["Tenant Sentinel Mesh"] - TN["Tenant Immune Node"] - TR["Tenant Response Effectors"] - TMEM["Tenant Immune Memory"] - TREC["Tenant Recovery Controller"] + TN["Tenant Immune Node — Staff"] + TR["Tenant Response Effectors — PEP"] + TMEM["Tenant Immune Memory — Staff"] + TREC["Tenant Recovery Controller — Engine"] TM --> TW TI --> TM @@ -995,19 +1074,27 @@ flowchart TB 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 -The tenant immune system owns: +The tenant immune **Staff** surface owns: -- tenant-specific security intent; -- application and data policies; -- tenant identities and delegated roles; +- tenant-specific security intent (genome consumption); - tenant-specific anomaly baselines; -- local incident correlation; -- local response decisions; -- tenant-private evidence; -- tenant-specific countermeasures; -- tenant recovery procedures. +- local incident correlation and judgment; +- bounded response *proposals*; +- tenant-private evidence references; +- tenant-specific countermeasures as published memory. + +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 @@ -1228,12 +1315,12 @@ Target latency: days to quarters. | VSM function | Kings Guard responsibility | |---|---| -| System 1 — Operations | Workload, application and tenant sentinels and effectors | -| System 2 — Coordination | Signal routing, deduplication, suppression and incident coordination | -| System 3 — Control | Tenant and platform response controllers | -| System 3* — Audit | Independent validation, forensic inspection and adversarial testing | -| System 4 — Intelligence | Threat research, simulation, adaptive policies and immune memory | -| System 5 — Policy | Security identity, principles, risk appetite and response authority | +| 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 (Staff) | +| 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 (`audit-core`, whitehat-security) | +| System 4 — Intelligence | Threat research, simulation, and governed immune memory (Staff; not a state plane) | +| System 5 — Policy | Doctrine (gate-house) compiled into the versioned policy package the PDP applies | The same mapping applies recursively to: @@ -1304,6 +1391,15 @@ response_authority: ## 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. | Posture | Meaning | Typical controls | @@ -1469,7 +1565,9 @@ erDiagram SUBJECT ||--o{ OBSERVATION : produces RESOURCE ||--o{ OBSERVATION : concerns 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 RESPONSE_ACTION ||--o{ RESPONSE_OUTCOME : produces RESPONSE_OUTCOME ||--o{ MEMORY_OBJECT : informs @@ -1485,14 +1583,18 @@ The data model must preserve separation among: - raw evidence; - normalized observation; +- phenotype and posture (Staff judgment); - attack hypothesis; -- decision; -- response authorization; -- action execution; +- decision (`access-engine` only); +- response authorization (the same decision record); +- action execution (PEP / actuation surface, unowned today); - outcome; - lesson; - policy change. +Immune memory may be derived from outcome and lesson. It MUST NOT appear as +an input arrow into DECISION. + --- ## 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. -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; - precedence; - exceptions; - reason; -- decision inputs; +- decision inputs (including posture as a claim, not as a verdict); - resulting constraints. --- @@ -1584,8 +1687,9 @@ Security observability includes both threat state and immune-system health. - sentinel coverage; - signal delivery latency; -- decision latency; -- response latency; +- judgment latency (Staff); +- decision latency (PDP); +- response latency (PEP / actuation, when the surface exists); - failed effectors; - stale trust posture; - policy distribution lag; @@ -1708,22 +1812,22 @@ kings-guard/ │ ├── immune-coordination/ │ ├── signal-fabric/ -│ ├── tenant-immune-node/ +│ ├── tenant-immune-node/ # Staff judgment, not a PDP │ ├── platform-immune-node/ │ ├── federation/ │ └── signal-schema/ │ -├── immune-decision/ -│ ├── policy-evaluation/ -│ ├── risk-evaluation/ +├── immune-judgment/ # Staff — not a second decision point +│ ├── phenotype/ +│ ├── posture/ │ ├── attack-hypothesis/ -│ ├── response-selection/ -│ └── decision-schema/ +│ ├── response-proposal/ +│ └── posture-schema/ │ -├── immune-response/ -│ ├── response-orchestrator/ -│ ├── effectors/ -│ ├── authority-control/ +├── immune-response/ # Engine + PEP; not a kings-guard tree +│ ├── proposal-contract/ # Staff emits; see ImmuneContracts.md +│ ├── effectors/ # PEP-shaped; actuation unowned +│ ├── authority-control/ # access-engine │ ├── escalation/ │ └── response-schema/ │ @@ -1772,9 +1876,9 @@ The architecture should stabilize contracts before selecting implementations. - Security Genome Contract; - Immune Observation Contract; - Immune Signal Contract; -- Decision Contract; +- Decision Contract (owned by `access-engine`; statute §17); - Response Authority Contract; -- Effector Contract; +- Effector Contract (Staff proposal shape; execution is PEP); - Response Outcome Contract; - Recovery Contract; - Memory Object Contract; @@ -1917,29 +2021,27 @@ A tenant workload attempts an external connection that is not declared in its Se ```mermaid sequenceDiagram participant W as Workload - participant S as Runtime Sentinel - participant N as Tenant Immune Node - participant D as Decision Engine - participant R as Regulation Controller - participant E as Network Effector - participant M as Immune Memory - participant H as Recovery Controller + participant S as Runtime Sentinel (PEP-shaped) + participant N as Tenant Immune Node (Staff) + participant D as access-engine (PDP) + participant E as Network Effector (PEP) + participant M as Immune Memory (Staff) + participant H as Recovery (Engine / runtime) 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 - N->>D: Request contextual assessment - D->>D: Compare identity, intent, posture and history - D->>R: Propose temporary workload isolation - R->>R: Validate authority, blast radius and TTL - R->>E: Authorize isolation - E->>W: Isolate workload + N->>N: Derive phenotype and posture + N->>D: Publish posture as an input claim plus a containment proposal + D->>D: Render the only authorization decision + D->>E: Decision record (actuation unowned today — intended hop) + E->>W: Isolate workload if and when actuation exists E->>N: Return action outcome N->>H: Request credential rotation and reconstitution H->>W: Replace with known-good workload H->>N: Return validation result - N->>M: Store evidence, action and outcome - M->>D: Update future decision context + N->>M: Store evidence, proposal, decision ref and outcome + Note over M,D: Memory is not a runtime input to the PDP ``` ### Result @@ -2106,14 +2208,14 @@ Security-relevant behaviour is attributable, normalized and routed to the correc Deliver: - tenant-local correlation; -- policy evaluation; - trust posture integration; -- response recommendations; -- tenant-private memory. +- response *recommendations* (proposals, not PDP evaluation); +- tenant-private memory that is not a runtime input to other layers. 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 @@ -2273,7 +2375,7 @@ The Kings Guard architecture is successful when the platform can demonstrate tha ## 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: diff --git a/workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md b/workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md index 0937bfb..1f19d9e 100644 --- a/workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md +++ b/workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md @@ -114,7 +114,7 @@ frontmatter through §36. T02–T04 slices are listed in §4 of that file. ```task id: KG-WP-0004-T02 -status: todo +status: done priority: high 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 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