Complete KG-WP-0004-T04: propose containment, do not actuate

Response ladder, authority grant, effector example, and Phase 5 now
separate Staff proposals from Engine/PEP execution. Actuation stays
unowned. Origin linkage matches WP-0003-T06.

Assistant: grok
Assistant-Session: 01a05ef1-9e5a-70f2-b0ff-0b05d6b38ae9

WORK-RECORDS.md

@@ -30,7 +30,7 @@
 | task | KG-WP-0004-T01 | done | — | 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 | done | — | 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 | done | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
 | task | KG-WP-0004-T05 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
 | intake | KG-IN-0001 | closed | — | intakes/intakes.md |
 | intake | KG-IN-0002 | closed | — | intakes/intakes.md |

specs/NetKingdomImmuneArchitecture.md

@@ -43,7 +43,8 @@ The system is intended to protect heterogeneous cloud environments containing:
 The architecture aims to preserve the platform's viability by enabling it to:
 
 1. distinguish intended from harmful behaviour;
-2. identify and contain disturbances near their origin;
+2. identify disturbances near their origin and *propose* containment
+   (Engine/PEP perform it, when an actuation surface exists);
 3. adapt defensive measures to new evidence;
 4. restore known-good operation after compromise;
 5. learn without violating tenant confidentiality;
@@ -225,9 +226,11 @@ An authenticated, typed message used to coordinate security assessment or respon
 
 ### 4.9 Effector
 
-A component authorized to perform a concrete defensive action.
+A **PEP-shaped** component authorized to perform a concrete defensive
+action under a decision record (or a recorded stance). kings-guard does
+not hold effectors. It emits an `effector_request` as a **proposal**.
 
-Examples:
+Examples of actions a PEP might perform, once actuation exists:
 
 - reject;
 - throttle;
@@ -315,13 +318,17 @@ Compromise of one compartment must not automatically compromise another.
 
 Disturbances should be handled as close to their origin as safely possible.
 
-Local components receive bounded authority and escalate when:
+Local **PEPs** apply an existing decision or a declared stance (§6.4 of
+the layer model). Staff components emit bounded *proposals* and escalate
+when:
 
 - evidence is insufficient;
 - impact may cross compartment boundaries;
-- response exceeds local authority;
+- the proposal exceeds what local PEPs may already enforce;
 - platform-level coordination is required.
 
+A Staff node does not receive a standing isolate grant.
+
 ### 6.5 Evidence Before Judgment
 
 Observations, interpretations, decisions and actions remain distinguishable.
@@ -336,17 +343,20 @@ This enables:
 
 ### 6.6 Reversible Automation Before Irreversible Action
 
-Automated response should prefer temporary, scoped and reversible controls.
+Where actuation exists, automated response should prefer temporary, scoped
+and reversible controls. Irreversible or high-impact actions require
+stronger evidence or approval.
 
-Irreversible or high-impact actions require stronger evidence or approval.
+kings-guard does not automate isolate. It proposes. The actuation surface
+is unowned and held at zero.
 
 ### 6.7 Recovery Before Perfect Prevention
 
 The system assumes that some controls will fail.
 
-Every critical capability must have:
+Every critical capability must have, as an **estate** property:
 
-- containment;
+- containment (Engine + PEP; unowned today);
 - restoration;
 - reconstitution;
 - validation;
@@ -423,8 +433,8 @@ Each level has:
 - a declared intent;
 - observable state;
 - policy;
-- bounded authority;
+- bounded proposal scope (Staff) or a decision/stance (PEP);
-- local memory;
+- local memory (Staff; not a state plane);
 - escalation rules;
 - recovery procedures.
 
@@ -902,32 +912,35 @@ immune_decision:
 ### 9.7 Response Plane
 
 **Layer: Engine + PEP. Actuation is unowned and held at zero (§9.2).**
-kings-guard proposes the rungs; it does not execute them. Execution, safety
+kings-guard proposes the rungs; it does not execute them.
-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.
+actuation surface exists. Until then the ladder is a vocabulary of
+**proposals** (Staff) and of **intended PEP actions** (Engine/PEP).
 
 #### Response Ladder
 
-| Level | Response | Typical effect |
+| Level | Kind | Staff (propose) | Engine / PEP (execute, when actuation exists) |
-|---|---|---|
+|---|---|---|---|
-| R0 | Observe | Collect additional evidence |
+| R0 | Observe | collect additional evidence | — |
-| R1 | Challenge | Require stronger authentication or attestation |
+| R1 | Challenge | request step-up | require stronger authentication or attestation |
-| R2 | Constrain | Reduce permissions, destinations or rate |
+| R2 | Constrain | propose reduced permissions, destinations or rate | reduce them under a decision record |
-| R3 | Degrade | Disable nonessential functions |
+| R3 | Degrade | propose disabling nonessential functions | disable them under a decision record |
-| R4 | Isolate | Quarantine a subject, workload or segment |
+| R4 | Isolate | propose quarantine of a subject, workload or segment | quarantine under a decision record |
-| R5 | Revoke | Invalidate sessions, credentials or authority |
+| R5 | Revoke | propose session/credential/authority invalidation | invalidate under a decision record |
-| R6 | Terminate | Stop malicious or uncertain execution |
+| R6 | Terminate | propose stopping execution | stop it under a decision record |
-| R7 | Reconstitute | Replace with known-good state |
+| R7 | Reconstitute | request replacement with known-good state | replace (runtime / Engine) |
-| R8 | Restore | Recover validated service and data |
+| R8 | Restore | request validated recovery | recover (runtime / Engine) |
-| R9 | Immunize | Distribute tested countermeasures |
+| R9 | Immunize | publish a tested countermeasure as evidence | distribute only via policy the PDP renders |
+
+R0 is Staff. R1–R9 change authority or runtime state; Staff may only
+propose them. No argument may assume they happen automatically.
 
 #### Response Safety Envelope
 
-Every automated action requires:
+Every **PEP / actuation** action, when the surface exists, requires:
 
-- authorized issuer;
+- a decision record from `access-engine`, or a recorded §6.4 stance;
 - permitted scope;
 - maximum blast radius;
 - time-to-live;
@@ -938,6 +951,9 @@ Every automated action requires:
 - escalation condition;
 - audit record.
 
+A Staff `effector_request` is not that action. It is the proposal that
+the PDP may render.
+
 ### 9.8 Recovery and Reconstitution Plane
 
 **Layer: Engine / runtime.** Staff may request reconstitution. It does not
@@ -1118,7 +1134,7 @@ The platform may override tenant policy only when required to:
 - prevent cross-tenant compromise;
 - preserve platform integrity;
 - satisfy mandatory legal obligations;
-- contain platform-level incidents;
+- contain platform-level incidents (Engine + PEP; not a Staff isolate);
 - enforce agreed minimum security controls.
 
 Every override must be:
@@ -1241,7 +1257,9 @@ Reassessment occurs when:
 
 ### 14.1 Fast Local Loop
 
-Purpose: immediate containment.
+Purpose: immediate **PEP** enforcement of an existing decision or declared
+stance. This is not kings-guard containing anything. The live example is
+`qonto-assistant`'s deny-escalation lockout.
 
 ```text
 sense
@@ -1258,7 +1276,7 @@ Examples:
 - block prohibited syscall;
 - deny unapproved egress;
 - throttle abusive request;
-- isolate a process.
+- isolate a process (PEP, under existing policy — not a Staff grant).
 
 ### 14.2 Tenant Adaptive Loop
 
@@ -1267,20 +1285,21 @@ Purpose: contextual tenant response.
 ```text
 correlate tenant observations
 → assess against tenant intent
-→ select bounded response
+→ emit a bounded proposal
+→ (PDP decides; PEP acts, when actuation exists)
 → observe outcome
 → update tenant memory
 ```
 
 Target latency: seconds to minutes.
 
-Examples:
+Examples of **Staff proposals** (not actions this repository performs):
 
-- revoke a tenant session;
+- request session revocation;
-- restrict an application;
+- request application restriction;
-- rotate tenant credentials;
+- request credential rotation;
-- isolate a tenant workload group;
+- request isolation of a tenant workload group;
-- deploy a tenant-specific detection.
+- publish a tenant-specific detection.
 
 ### 14.3 Platform Coordination Loop
 
@@ -1289,9 +1308,9 @@ Purpose: protect shared infrastructure and tenants.
 ```text
 aggregate platform signals
 → identify shared or cross-tenant impact
-→ coordinate platform response
+→ propose / coordinate platform response
-→ validate containment
+→ validate a PEP containment outcome, when one exists
-→ distribute safe countermeasures
+→ distribute safe countermeasures as evidence, not as extra authority
 ```
 
 Target latency: seconds to hours.
@@ -1335,11 +1354,14 @@ The same mapping applies recursively to:
 
 ## 16. Response Authority Model
 
-No component receives unlimited security authority.
+No component receives unlimited security authority. A **Staff** node never
+receives isolate, revoke, or terminate as a power it exercises. Those are
+authority-changing operations: the PDP renders them, a PEP enforces them,
+and the actuation surface is unowned today.
 
 ### 16.1 Authority Dimensions
 
-Authority is constrained by:
+Bounds on a future Engine/PEP grant (not on a Staff node):
 
 - tenant;
 - compartment;
@@ -1352,12 +1374,27 @@ Authority is constrained by:
 - approval requirement;
 - operating mode.
 
-### 16.2 Example Authority Grant
+### 16.2 Example — Staff proposal, then Engine/PEP grant
 
 ```yaml
+# Staff emits this. It is not an authorization.
+effector_request:
+  originating_observation_id: kg:obs:9876
+  originating_signal_id: kg:sig:9876
+  target_system: runtime-pep
+  action: isolate
+  authority_boundary: advisory_only
+  restrictive_direction: request_containment
+  requires_human_approval: false
+  stream_completeness: unknown
+  reason: "Genome-prohibited egress; propose workload quarantine."
+
+# Engine/PEP grant, if and when actuation exists. Not issued to a Staff node.
 response_authority:
   authority_id: kg:authority:tenant-isolator
-  subject_id: kg:subject:tenant-immune-node-a
+  subject_id: kg:pep:runtime-isolator
+  issued_by: access-engine
+  decision_ref: kg:decision:123
 
   scope:
     tenant_id: tenant-a
@@ -1380,12 +1417,6 @@ response_authority:
   limits:
     maximum_ttl: PT1H
     maximum_concurrent_targets: 20
-    minimum_confidence: 0.85
-
-  escalation_required_for:
-    - terminate
-    - restore-data
-    - revoke-human-admin
 ```
 
 ---
@@ -1735,6 +1766,9 @@ Every security component publishes:
 
 ### 23.3 Containment
 
+Estate KPIs of the **actuation surface** (Engine + PEP), which is unowned
+today. kings-guard does not discharge them.
+
 - mean time to constrain;
 - mean time to isolate;
 - containment success rate;
@@ -1832,7 +1866,7 @@ kings-guard/
 │   ├── escalation/
 │   └── response-schema/
 │
-├── immune-recovery/
+├── immune-recovery/                 # Engine / runtime; Staff may request
 │   ├── reconciliation/
 │   ├── reconstitution/
 │   ├── secret-rotation/
@@ -1888,30 +1922,33 @@ The architecture should stabilize contracts before selecting implementations.
 
 ### 25.2 Effector Contract
 
+Staff emits a **proposal**. Origin linkage is mandatory (WP-0003-T06).
+Authority is not widened. The PEP result, when actuation exists, cites the
+decision that authorized it — not the Staff node.
+
 ```yaml
 effector_request:
   request_id: uuid
-  decision_ref: kg:decision:123
+  originating_observation_id: kg:obs:9876
+  originating_signal_id: kg:sig:9876
+  target_system: runtime-pep
   target_ref: kg:subject:456
   action: isolate
-  scope: workload
+  authority_boundary: advisory_only
-  ttl: PT15M
+  restrictive_direction: request_containment
-  authority_ref: kg:authority:tenant-isolator
+  requires_human_approval: false
-  expected_outcome: "No network or workload execution outside forensic channel."
+  stream_completeness: unknown
-  rollback:
+  reason: "Genome-prohibited egress observed; propose workload quarantine."
-    mode: automatic
-    condition: "ttl-expired or explicit-release"
-  validation:
-    required: true
-    checks:
-      - network-isolation-confirmed
-      - execution-suspended
 ```
 
 ```yaml
+# PEP / Engine artifact after a decision. Not a kings-guard output.
 effector_result:
   request_id: uuid
-  effector_id: kg:effector:runtime-01
+  originating_observation_id: kg:obs:9876
+  originating_signal_id: kg:sig:9876
+  decision_ref: kg:decision:123
+  effector_id: kg:pep:runtime-01
   started_at: 2026-07-23T18:00:03Z
   completed_at: 2026-07-23T18:00:04Z
   status: successful
@@ -2047,12 +2084,13 @@ sequenceDiagram
 
 ### Result
 
-- the local attempt is blocked immediately;
+- the local attempt is blocked immediately by a PEP under existing policy;
-- the tenant compartment contains the possible compromise;
+- Staff publishes posture and a containment *proposal*;
-- credentials are rotated;
+- `access-engine` is the only component that may authorize isolation;
-- the workload is replaced rather than merely restarted;
+- isolation, rotation and reconstitution are Engine/PEP, and actuation is
-- the restored workload is validated;
+  unowned today — the hops are the intended loop, not a claim they ran;
-- the incident becomes governed tenant memory;
+- the tenant compartment is the *unit* of containment, not the actor;
+- the incident becomes governed tenant memory, which is not a PDP input;
 - a shareable attack characteristic may be submitted to platform memory without exporting tenant-private evidence.
 
 ---
@@ -2218,20 +2256,24 @@ Success condition:
 Common tenant incidents can be judged without central manual correlation.
 Policy evaluation remains `access-engine`.
 
-### Phase 5 — Bounded Automated Response
+### Phase 5 — Bounded Proposal (actuation unowned)
 
 Deliver:
 
-- response authority model;
+- reconstructable containment *proposals* (origin observation and signal,
+  explicit `authority_boundary`);
+- restrictive-direction vocabulary (reduce / step-up / request containment);
+- no Staff isolate/revoke/terminate grant.
+
+This phase is complete when proposals are well-formed and reconstructable,
+**not** when anything is contained. Actuation is an Engine concept held at
+zero. No argument may assume selected incidents are contained automatically.
+
+Engine/PEP follow-on (not this repository, not this phase):
+
+- response authority model on the PDP;
 - reversible effectors;
-- response leases;
+- response leases, rollback, action validation, response budgets.
-- rollback;
-- action validation;
-- response budgets.
-
-Success condition:
-
-Selected high-confidence incidents can be contained automatically without uncontrolled blast radius.
 
 ### Phase 6 — Recovery and Reconstitution
 
@@ -2279,22 +2321,24 @@ Multiple environments can share useful defensive knowledge without exposing tena
 
 ## 32. Initial Repository Deliverables
 
-The initial `kings-guard` repository should contain:
+The `kings-guard` repository holds Staff contracts and this architecture
+map. It does not hold identity issuance, PDP, or effector-*execution* specs.
+
+Present:
 
 1. `INTENT.md`
-2. `NetKingdomImmuneArchitecture.md`
+2. `specs/NetKingdomImmuneArchitecture.md` (this file)
-3. `SecurityGenomeSpecification.md`
+3. `specs/ImmuneContracts.md`
-4. `IdentityAndAttestationContract.md`
+4. `docs/AdjacentSystemBoundary.md`
-5. `TenantCompartmentStandard.md`
+5. `docs/pilots/QontoAssistantPosturePilot.md`
-6. `ImmuneObservationSchema.md`
+6. `src/kings_guard/` (observation → posture → advisory proposal)
-7. `ImmuneSignalSchema.md`
+
-8. `ResponseAuthorityStandard.md`
+Not this repository (Engine / Tooling / PEP owners):
-9. `EffectorInterfaceSpecification.md`
+
-10. `ImmuneMemoryModel.md`
+- identity and attestation contracts (`key-cape`, `user-engine`);
-11. `DeploymentProfiles.md`
+- decision-record schema (`access-engine`);
-12. `ThreatAndFailureModeCatalog.md`
+- effector *execution* interface (unowned actuation surface);
-13. `ImplementationRoadmap.md`
+- secret-custody and recovery-runtime specs.
-14. `ArchitectureDecisionRecords/`
 
 ---
 
@@ -2310,15 +2354,20 @@ Every tenant has an explicit security boundary, policy scope, evidence scope, re
 
 ### AD-003 — Security Is Recursive
 
-The same observation, decision, response, recovery and learning pattern applies from workload to federation level.
+The same **observe → judge → propose** pattern applies from workload to
+federation level. Decide and act sit in Engine/PEP at every level. Recursion
+does not create a Staff decision point.
 
 ### AD-004 — Evidence Is Distinct From Interpretation
 
 Raw evidence, observations, hypotheses, decisions and actions are separate entities.
 
-### AD-005 — Automated Responses Are Bounded
+### AD-005 — Proposals Are Bounded; Actions Are Engine/PEP
 
-Every automated action is limited by scope, authority, duration, evidence threshold and rollback requirements.
+Every Staff *proposal* is limited by scope, authority boundary, duration
+and reconstructability to its origin. Every automated *action*, when
+actuation exists, is limited by a decision record, duration, evidence
+threshold and rollback. kings-guard does not perform the action.
 
 ### AD-006 — Recovery Is a First-Class Security Capability
 
@@ -2341,7 +2390,9 @@ Implementations may change without changing the stable Kings Guard capability mo
 ## 34. Open Questions
 
 1. How should trust posture dimensions be normalized across different runtime types?
-2. Which response actions may be authorized autonomously at each recursive level?
+2. Which *proposals* may Staff emit at each recursive level, and which PEP
+   stances already exist? (Autonomy of authorization is a second decision
+   point and is not on the table.)
 3. Which evidence classes may be federated across tenants?
 4. How should tenants inspect or challenge platform-level security overrides?
 5. Which Security Genome fields are mandatory for initial admission?
@@ -2363,7 +2414,9 @@ The Kings Guard architecture is successful when the platform can demonstrate tha
 - intended behaviour is explicitly declared;
 - tenant boundaries are technically enforceable;
 - security observations are attributable and contextualized;
-- local disturbances can be contained locally;
+- local disturbances can be contained locally by Engine/PEP, with Staff
+  proposing; actuation is unowned today so this criterion is not claimed
+  as discharged;
 - high-impact actions require proportionally stronger authority;
 - compromised components can be reconstituted;
 - recovery outcomes are validated;
@@ -2384,18 +2437,20 @@ Its defining sequence is:
 identity
 → intent
 → observation
-→ assessment
+→ judgment (posture)
-→ bounded response
+→ bounded proposal
+→ decision (access-engine)
+→ actuation (unowned)
 → recovery
 → validation
-→ memory
+→ memory (not a state plane)
 ```
 
 Its defining structural principles are:
 
 - identity instead of location-based trust;
 - compartmentation instead of a trusted interior;
-- local autonomous response with bounded authority;
+- local PEP enforcement and Staff proposals, not Staff isolate grants;
 - recovery as a peer of prevention and detection;
 - evidence separated from interpretation;
 - adaptive memory with provenance and decay;

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

@@ -179,7 +179,7 @@ the same way. Head note still cites v0.6 / KG-IN-0002 — that rewrite is T05.
 
 ```task
 id: KG-WP-0004-T04
-status: todo
+status: done
 priority: high
 state_hub_task_id: "bbb4c1aa-2808-5fde-8f9b-7fb7730f13c7"
 ```
@@ -205,6 +205,13 @@ Done when:
 - Phase 5 cannot be read as "kings-guard will automatically contain";
 - the effector example is a proposal, reconstructable to its origin.
 
+**Done 2026-09-02:** §9.7 ladder is propose vs execute; safety envelope is
+PEP/actuation. §16 grant is no longer issued to a Staff node. §25.2
+`effector_request` carries origin observation/signal, `advisory_only`, and
+`request_containment`. Phase 5 is bounded proposal; success is
+reconstructability, not automatic containment. Fast local loop named as PEP
+(qonto-assistant). AD-003/AD-005 and §35/§36 match propose-not-act.
+
 ## Task: Prove no Staff decision point; refresh the layer note
 
 ```task