10 changed files with 31 additions and 458 deletions
--- a/.repo-manager/index.json
+++ b/.repo-manager/index.json
@ -1,149 +0,0 @@
 {
  "schema": "repo_manager.index.v1",
  "slug": "layer-model-assent",
  "repo_root": "/home/worsch/kings-guard",
  "head_sha": "7c8ef38ee0603c4ca23e69abaff689b86da752b4",
  "observed_at": "2026-08-28T19:30:17.391432Z",
  "source_fingerprint": "ff379cda32bd3d625590480dbf164739c18022680a8390e4cd6a48514324cc5c",
  "source_files": [
    ".repo-classification.yaml",
    "INTENT.md",
    "intakes/intakes.md",
    "workplans/KG-WP-0001-statehub-bootstrap.md",
    "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md"
  ],
  "work_records": [
    {
      "kind": "workplan",
      "id": "KG-WP-0001",
      "status": "finished",
      "title": "Bootstrap State Hub integration",
      "source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
      "uuid": "b7ff79b9-ae27-4a46-a782-49482392eb83",
      "parent_id": null,
      "extra": {}
    },
    {
      "kind": "task",
      "id": "KG-WP-0001-T01",
      "status": "done",
      "title": "Review Generated Integration Files",
      "source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
      "uuid": "add34171-9f18-48b9-a88e-07ea34cb6382",
      "parent_id": "KG-WP-0001",
      "extra": {}
    },
    {
      "kind": "task",
      "id": "KG-WP-0001-T02",
      "status": "done",
      "title": "Verify Local Developer Workflow",
      "source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
      "uuid": "17fb3a0c-91c5-4b45-967e-962ef6c89ac5",
      "parent_id": "KG-WP-0001",
      "extra": {}
    },
    {
      "kind": "task",
      "id": "KG-WP-0001-T03",
      "status": "done",
      "title": "Seed First Real Workplan",
      "source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
      "uuid": "5b5f56d9-7e89-43b6-94c3-db4461e9eed4",
      "parent_id": "KG-WP-0001",
      "extra": {}
    },
    {
      "kind": "workplan",
      "id": "KG-WP-0002",
      "status": "finished",
      "title": "Canonical immune contracts and first posture pilot",
      "source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
      "uuid": "5c5c5a26-dfca-4d42-86a7-b87877677207",
      "parent_id": null,
      "extra": {}
    },
    {
      "kind": "task",
      "id": "KG-WP-0002-T01",
      "status": "done",
      "title": "Task: Define canonical immune contracts",
      "source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
      "uuid": "9982a3b4-1e65-493a-9b61-322f23d4fd2d",
      "parent_id": "KG-WP-0002",
      "extra": {}
    },
    {
      "kind": "task",
      "id": "KG-WP-0002-T02",
      "status": "done",
      "title": "Task: Write adjacent-system boundary contract",
      "source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
      "uuid": "0c44035e-b1b8-4f5d-8a6c-e6514b4bc897",
      "parent_id": "KG-WP-0002",
      "extra": {}
    },
    {
      "kind": "task",
      "id": "KG-WP-0002-T03",
      "status": "done",
      "title": "Task: Scaffold a minimal posture loop",
      "source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
      "uuid": "c88a7da6-a9ff-4bd9-ba47-7c199321666b",
      "parent_id": "KG-WP-0002",
      "extra": {}
    },
    {
      "kind": "task",
      "id": "KG-WP-0002-T04",
      "status": "done",
      "title": "Task: Choose and specify the first pilot lane",
      "source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
      "uuid": "77e1dc69-9902-4381-8028-ce1cfac7e9d5",
      "parent_id": "KG-WP-0002",
      "extra": {}
    },
    {
      "kind": "intake",
      "id": "KG-IN-0001",
      "status": "open",
      "title": "Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry",
      "source_path": "intakes/intakes.md",
      "uuid": null,
      "parent_id": null,
      "extra": {
        "record": {
          "id": "KG-IN-0001",
          "kind": "intake",
          "title": "Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry",
          "status": "open",
          "origin": "cross-repo",
          "origin_ref": "gate-house GH-DEC-2026-001",
          "priority": "medium",
          "owner": "kings-guard",
          "requested_by": "gate-house",
          "standard": "net-kingdom/canon/standards/security-layer-model_v0.1.md",
          "description": "gate-house asks kings-guard to assent to its placement in the NetKingdom security layer model. (1) kings-guard is Staff \u2014 agentic and non-deterministic \u2014 not an Engine. Acting at runtime does not make a repository an Engine; being agentic makes it Staff. (2) Consequently its self-description as an adaptive security control plane needs revisiting: control plane is Engine-layer vocabulary (standard section 8). This is not a demotion \u2014 it is the reason kings-guard may contain a threat only by calling an engine, never by reaching into OpenBao or a cluster directly (the binding rule, standard section 5: Staff never touches Tooling directly). (3) The posture contract with gate-house and its asymmetry: adaptive systems may reduce authority, require step-up, or request containment; they must never probabilistically manufacture additional authority. kings-guard publishes posture, gate-house defines its authority meaning, access-engine renders it. If the binding rule is impractical for containment in a real incident, say so \u2014 that is exactly the kind of finding that should change the doctrine rather than be worked around.",
          "created": "2026-08-28T19:30:17.201213Z",
          "updated": "2026-08-28T19:30:17.201213Z"
        }
      }
    }
  ],
  "events": [
    {
      "type": "repo.command.applied",
      "command": "repo.work.create_intake",
      "operation": "create",
      "correlation_id": "f9b8b130-71f6-41b9-9f06-e28d2abda2d4",
      "kind": "intake",
      "id": "KG-IN-0001",
      "git_sha": "7c8ef38ee0603c4ca23e69abaff689b86da752b4",
      "files_touched": [
        "intakes/intakes.md"
      ],
      "source": "repo-manager",
      "emitted_at": "2026-08-28T19:30:17.391507Z"
    }
  ]
 }
--- a/AGENTS.md
+++ b/AGENTS.md
@ -2,12 +2,7 @@
 ## Repo Identity
-**Purpose:** Adaptive immune defence for complex multi-tenant cloud environments.
+**Purpose:** Adaptive immune security control plane for complex multi-tenant cloud environments.
 **Layer:** Staff (NetKingdom Security Layer Model v0.1). Never open a direct
 client for a Tooling-layer system (OpenBao, key-cape components, a database, a
 cluster); route every such need through the owning engine and record the gap in
 `INTENT.md`. Never render or cache an authorization decision.
 **Domain:** infotech
 **Repo slug:** kings-guard
@ -125,8 +120,8 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 ## Repo-Specific Notes
 This repo is no longer docs-only. It now has a **small Python 3.12 scaffold**
-for contract modeling and posture evaluation. It is a Staff-layer repository:
+for contract modeling and posture evaluation, but it is still **not** a
-not a long-running enforcement service, and not a control plane.
+long-running control-plane service.
 ## Working Set
--- a/INTENT.md
+++ b/INTENT.md
@ -1,28 +1,19 @@
 # INTENT
-> **Layer: Staff.** *(NetKingdom Security Layer Model v0.1, §4 catalog —
+> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed
-> `net-kingdom/canon/standards/security-layer-model_v0.1.md`; ratified by
+> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines →
-> `gate-house/decisions/decisions.md` GH-DEC-2026-001; assented here by
+> Staff**, layered by determinism and by the kind of artifact each layer produces.
-> `decisions/decisions.md` KG-DEC-2026-001 on 2026-08-28.)*
+> Findings and the argument behind them:
 > `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
 > The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
 > ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001.
 >
-> kings-guard is **interactive and non-deterministic**: adaptive defence,
+> The layer rule that binds every repository: **Staff never touches tooling
-> observation, containment. Acting at runtime does not make a repository an
+> directly. It acts only through engine APIs.**
 > Engine; being agentic makes it Staff.
 >
-> **The binding rule (§5): Staff never touches Tooling directly. It acts only
+> **This repository is Staff — interactive, non-deterministic; adaptive defence.** Add the layer label. The self-description **"adaptive security control plane"** needs revisiting: control-plane vocabulary belongs to the Engine layer, and kings-guard is agentic and therefore Staff. This is not a demotion — it is the reason kings-guard may contain a threat only by calling an engine, never by reaching into OpenBao or a cluster directly. Also state the posture contract with gate-house and its asymmetry: **adaptive systems may reduce authority, require step-up, or request containment; they must never probabilistically manufacture additional authority.**
 > through Engine APIs.** kings-guard holds no direct client for a Tooling-layer
 > system — no database connection, no OpenBao client, no cluster mutation. It
 > may contain a threat only by calling an engine. Where no engine exposes a
 > capability kings-guard needs, that is raised as an **engine gap**, never
 > solved locally; the open gaps are listed under *System boundary* below.
 >
-> **Posture contract.** kings-guard **publishes** posture; `gate-house` defines
+> *This note records what should change. The body below is not yet adapted.*
 > its authority meaning; `access-engine` renders it. Posture is not a privilege
 > source. The asymmetry is absolute: kings-guard may **reduce** authority,
 > **require step-up**, or **request containment**; it MUST NOT probabilistically
 > manufacture additional authority. Every effector request it emits therefore
 > carries an explicit authority boundary and is advisory unless the owning
 > system has already delegated a narrow, deterministic action lane.
 > This file captures **why this repository exists**, the **direction it is
 > moving toward**, and the **kind of system it is meant to become**.
@ -33,14 +24,9 @@
 ## One-liner
-**Recursive adaptive defence for complex cloud environments: it declares
+**Recursive adaptive security control plane for complex cloud environments: it
-healthy intent, detects harmful deviation, requests bounded containment through
+declares healthy intent, detects harmful deviation, contains damage locally,
-the owning engines, helps restore known-good operation, and retains governed
+restores known-good operation, and retains governed defensive memory.**
 defensive memory.**
 *"Control plane" is Engine-layer vocabulary (layer model §8) and is no longer
 used here for kings-guard. kings-guard judges and proposes; engines decide and
 act.*
 ---
@ -130,31 +116,13 @@ Kings Guard owns the **adaptive security assessment and response layer**.
 | Concern | Primary owner | Kings Guard responsibility |
 | --- | --- | --- |
-| Identity, authentication, MFA, and verified claims | `key-cape` (Tooling) | Consume identity and attestation as security inputs — **through `user-engine` / `access-engine`, never by connecting to key-cape's components**; do not replace identity. |
+| Identity, authentication, MFA, and verified claims | `key-cape` and related IAM systems | Consume identity and attestation as security inputs; do not replace identity. |
-| Resource authorization and decision logs | `access-engine` (currently named `flex-auth`) | Contribute posture and risk context; never render or cache an authorization decision — it is the estate's only decision point (layer model §6). |
+| Resource authorization and decision logs | `flex-auth` | Contribute posture and risk context; do not become the authorization control plane. |
-| Secret custody, delivery, leases, and rotation | OpenBao (Tooling), fronted by `secrets-engine` (Engine) | Consume secret-access evidence **through `secrets-engine`**, never through an OpenBao client; do not hold raw secret authority. |
+| Secret custody, delivery, leases, and rotation | `railiance-platform` and `secrets-engine` | Consume secret-access evidence and drive defensive posture; do not hold raw secret authority. |
 | Operational SSH certificate issuance and access routing | `ops-warden` | Supply posture, evidence, or future response hooks; do not become the SSH issuing lane. |
 | Infrastructure, runtime, and platform execution | Railiance repos and workload operators | Signal constraints, isolation, and reconstitution needs; do not own deployment mechanics. |
 | Workstream and task coordination | `state-hub` | Emit non-secret evidence and integration events where appropriate; do not become a work tracker. |
 #### Declared engine gaps
 Capabilities kings-guard needs that no engine exposes today. Under the binding
 rule these are gaps to close in the owning engine, not work to route around.
 None is a standing licence to reach into Tooling.
 | Gap | Needed for | Owning engine | Status |
 | --- | --- | --- | --- |
 | Authentication and assurance evidence (token assurance, attestation outcomes, authentication anomalies) exposed as an engine surface | identity-drift posture | `user-engine` / `access-engine` | open — no engine surface; kings-guard consumes fixtures only |
 | Secret-use evidence (lease, revocation, mount and rotation metadata) exposed as an engine surface | secret-abuse posture | `secrets-engine` | open — no engine surface; kings-guard consumes fixtures only |
 | A containment surface — reduce authority, require step-up, isolate a workload — callable as a deterministic engine API, and available while an incident is in progress | bounded response | `access-engine`, runtime engines | open — see KG-DEC-2026-001 §Finding |
 Until a gap closes, the corresponding posture lane stays advisory and
 fixture-driven. kings-guard MUST NOT open a direct path to the Tooling system
 to fill one. If diagnostic read-only observation of Tooling ever becomes
 unavoidable, the layer model requires it to be declared in this file and
 treated as a gap to close; **no such observation is declared today.**
 ---
 ## Design Principles
@ -203,7 +171,7 @@ mandatory product stack.
 Kings Guard is:
- an adaptive defence concept and implementation home, in the Staff layer;
+- an adaptive security control-plane concept and implementation home;
 - a contract layer for healthy intent, observations, signals, posture, and
  effectors;
 - a coordination system for detection, containment, recovery, and memory;
--- a/README.md
+++ b/README.md
@ -3,10 +3,6 @@
 Adaptive security contracts and posture-evaluation scaffold for NetKingdom's
 immune-architecture work.
 **Layer: Staff** (NetKingdom Security Layer Model v0.1). kings-guard publishes
 posture and requests bounded response through engine APIs; it never touches
 Tooling directly and never renders an authorization decision.
 ## Current slice
 This repository now contains four aligned pieces:
@ -16,8 +12,8 @@ This repository now contains four aligned pieces:
 - `specs/ImmuneContracts.md` for the first canonical contract layer
 - `src/kings_guard/` plus `tests/` for a minimal posture loop scaffold
-The current implementation is intentionally narrow. It does **not** enforce
+The current implementation is intentionally narrow. It does **not** provide a
-anything. It provides:
+running security control plane yet. It provides:
 - typed contracts for security genome, phenotype, observation, posture,
  signal, effector request, and immune memory entry;
--- a/SCOPE.md
+++ b/SCOPE.md
@ -4,15 +4,6 @@
 ---
 ## Layer
 **Staff** — interactive, non-deterministic; adaptive defence, observation,
 containment. Binding rule: kings-guard never touches Tooling directly; it acts
 only through Engine APIs. See `INTENT.md` and
 `net-kingdom/canon/standards/security-layer-model_v0.1.md`.
 ---
 ## One-liner
 Adaptive security assessment and bounded-response layer for multi-tenant cloud
@ -47,12 +38,6 @@ without replacing those systems' primary authority.
 ## Out of Scope
 - Identity issuance, login, MFA, or token minting.
 - Any direct client for a Tooling-layer system (OpenBao, key-cape components,
  a database, a cluster) — every such need routes through the owning engine.
 - Rendering or caching an authorization decision; `access-engine` is the
  estate's only decision point.
 - "Control plane" as a self-description — that vocabulary belongs to the
  Engine layer.
 - Authorization policy administration or final resource allow/deny decisions.
 - Secret custody, lease issuance, or raw secret-value delivery.
 - Infrastructure provisioning, workload deployment, or cluster/platform
@ -70,8 +55,8 @@ without replacing those systems' primary authority.
 - A minimal Python reference scaffold exists under `src/kings_guard/` with
  fixture-driven tests under `tests/`.
 - The implementation currently evaluates normalized observations and emits
-  posture/signal results for one bounded pilot lane; it is not an enforcement
+  posture/signal results for one bounded pilot lane; it is not yet a running
-  service and will not become one.
+  control plane or integrated enforcement service.
 ---
--- a/WORK-RECORDS.md
+++ b/WORK-RECORDS.md
@ -17,4 +17,3 @@
 | task | KG-WP-0002-T02 | done | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md |
 | task | KG-WP-0002-T03 | done | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md |
 | task | KG-WP-0002-T04 | done | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md |
 | intake | KG-IN-0001 | open | — | intakes/intakes.md |
--- a/decisions/decisions.md
+++ b/decisions/decisions.md
@ -1,152 +0,0 @@
 # Decision records
 ## KG-DEC-2026-001 — Assent to Staff placement, release of control-plane vocabulary, and the posture asymmetry
 ```yaml
 id: KG-DEC-2026-001
 kind: decision
 title: Assent to Staff placement, release of control-plane vocabulary, and the posture
  asymmetry
 status: resolved
 owner: Bernd Worsch
 repo: kings-guard
 standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
 origin_ref: KG-IN-0001
 related:
 - gate-house/decisions/decisions.md GH-DEC-2026-001
 - gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md
 affects:
 - kings-guard
 - gate-house
 - net-kingdom
 - access-engine
 - secrets-engine
 - user-engine
 created: '2026-08-28'
 updated: '2026-08-28'
 decided_by: Bernd Worsch
 disposition: assent-with-finding
 ```
 ## Context
 `gate-house` raised intake `KG-IN-0001` asking `kings-guard` to assent to its
 placement in the NetKingdom Security Layer Model v0.1: Staff, not Engine; the
 release of "control plane" as a self-description; and the posture contract with
 its asymmetry. The request explicitly invited challenge to §5 — the binding
 rule — if routing containment through engine APIs proves impractical in a real
 incident.
 ## Decision
 **Assent to all three points, with one finding against §5 that gate-house
 should rule on.**
 ### 1. Staff placement — assented
 kings-guard is agentic and non-deterministic. Its outputs are posture
 judgments, typed signals, and bounded requests — not a deterministic result
 from an authoritative input state. It fails the Engine test in §3.3 on its
 defining property, and it fails it by design: intent-versus-behavior judgment
 is inference, and inference is not an authority. Staff is the correct layer,
 and "acting at runtime does not make a repository an Engine" resolves the only
 plausible objection kings-guard had.
 `INTENT.md` now declares the layer.
 ### 2. Control-plane vocabulary — released
 "Control plane" is released to the Engine layer. The one-liner, `SCOPE.md`,
 `README.md`, `AGENTS.md`, and the adjacent-system boundary have been reworded:
 kings-guard **judges and proposes; engines decide and act.**
 We accept the framing that this is not a demotion. It is the same statement as
 the binding rule, read from the other end: a repository that may not reach into
 OpenBao or a cluster directly has no plane to control, and saying so plainly
 removes an overlap that was invisible in this repo's own documents.
 Residual: `specs/NetKingdomImmuneArchitecture.md` uses "control plane" in
 several places describing an estate-wide arrangement of deterministic
 authorities. A layer note now scopes those readings; the full sweep is handed
 off as intake **KG-IN-0002**.
 ### 3. Posture contract and asymmetry — assented, and already implemented
 kings-guard **publishes** posture; gate-house defines its authority meaning;
 access-engine renders it. Posture is not a privilege source.
 The asymmetry — reduce authority, require step-up, request containment; never
 probabilistically manufacture additional authority — is adopted as an invariant
 of this repository, and the scaffold already satisfies it: every
 `EffectorRequest` carries an explicit `authority_boundary`, and the values in
 use are `advisory_only` and `metadata_only`. No code path widens authority.
 ### Conformance at time of assent
 Per layer model §10, checked and clean:
 - `pyproject.toml` declares **zero runtime dependencies** — no database driver,
  no OpenBao client, no cluster client. §5 holds mechanically.
 - No module exposes an authorization decision surface. §6 holds.
 - No read-only Tooling observation is claimed, so §5's declared-exception path
  is unused.
 ## Finding — §5 is right, and currently undischargeable for containment
 gate-house asked whether the binding rule is impractical for containment during
 a real incident. Our answer is **no — do not weaken it** — but the rule has a
 consequence the standard does not yet state.
 **Do not weaken it.** The three obvious pressures do not survive examination:
 - *Latency.* The asymmetry means kings-guard's only available actions point in
  the safe direction. A slow authority-reducing call is a slow safe action, not
  a dangerous one. Latency is not a reason to bypass an engine.
 - *Blast radius.* A direct path is wider than an engine call, not narrower.
  The engine is what bounds the radius.
 - *Engine unavailable.* This is the real pressure, and it is exactly where a
  break-glass path is most dangerous. An incident is when an attacker most
  wants the shortcut, and a containment path that bypasses the decision point
  is an authority path in the other direction the moment it is subverted. It
  is the "small convenience" §6 names. We do not want it, and we ask that
  gate-house not grant it to us.
 **But:** §4 catalogs kings-guard as owning "adaptive defence, observation,
 **containment**", while **no engine exposes a containment surface today** —
 nothing to reduce authority, require step-up, or isolate a workload as a
 deterministic API. Under §5, correctly obeyed, kings-guard's containment
 capability is therefore not degraded but **zero**. The charter in §4 and the
 rule in §5 are consistent in principle and unsatisfiable together in practice
 until that engine surface exists.
 Two requests to gate-house, either of which resolves it:
 1. **Rule that a containment capability MUST be engine-exposed before a Staff
   repository may be catalogued as owning containment** — so that §4 does not
   assign a responsibility §5 forbids discharging. Alternatively, mark
   kings-guard's containment claim as pending the engine gap.
 2. **Rule that the degraded-mode fallback belongs inside the engine, not in
   Staff.** If containment must survive partial failure, the deterministic
   "fail to reduced authority" default belongs to `access-engine`, applied when
   it cannot reach its own inputs. That keeps the decision at the decision
   point and keeps the fallback deterministic, which a Staff-layer fallback
   could never be.
 The three open engine gaps — authentication/assurance evidence, secret-use
 evidence, and the containment surface — are recorded in `INTENT.md` under
 *Declared engine gaps*. Until they close, the corresponding posture lanes stay
 advisory and fixture-driven, which is the honest state and not a workaround.
 ## Consequences
 - kings-guard declares Staff in `INTENT.md` and stops describing itself as a
  control plane.
 - Evidence from `key-cape` and OpenBao is routed through `user-engine` /
  `access-engine` and `secrets-engine` respectively; the boundary document no
  longer implies a direct read.
 - The `qonto-assistant` pilot is confirmed as the layer-clean lane: it needs no
  Tooling client, because the assistant publishes its own genome and audit
  stream.
 - kings-guard's assent removes one of the two adaptations §11 lists as
  outstanding. The standard remains proposed pending `flex-auth` and
  `ops-warden`.
--- a/docs/AdjacentSystemBoundary.md
+++ b/docs/AdjacentSystemBoundary.md
@ -30,24 +30,17 @@ The following rules apply to every integration below:
   advisory unless the owning system already delegates a narrow action lane.
 4. `kings-guard` must preserve **tenant isolation**: any retained evidence or
   memory must stay bounded by declared confidentiality rules.
 5. `kings-guard` is a **Staff-layer** repository and is bound by §5 of the
   NetKingdom Security Layer Model v0.1: it never holds a direct client for a
   Tooling-layer system. Evidence from Tooling (OpenBao, key-cape components)
   is consumed **through the owning engine**. Where no engine surface exists,
   the lane stays fixture-driven and the gap is declared in `INTENT.md`.
 6. `kings-guard` never renders or caches an authorization decision.
   `access-engine` is the estate's only decision point (layer model §6).
 ## 3. System-by-System Boundary
 | Adjacent system | Primary authority | Evidence consumed by `kings-guard` | Signals returned by `kings-guard` | Non-goals |
 | --- | --- | --- | --- | --- |
-| `key-cape` **(Tooling — reach via `user-engine` / `access-engine`)** | verified identity, login, MFA, assurance claims | token assurance level, attestation outcomes, claim provenance, authentication anomalies | posture hints about assurance drift or identity inconsistency | minting tokens, login flow, MFA lifecycle |
+| `key-cape` | verified identity, login, MFA, assurance claims | token assurance level, attestation outcomes, claim provenance, authentication anomalies | posture hints about assurance drift or identity inconsistency | minting tokens, login flow, MFA lifecycle |
-| `access-engine` (currently `flex-auth`) | resource authorization policy, decision logs, protected-system registry | live allow/deny decisions, decision explanations, policy version, decision-rate anomalies | risk context or posture hints that a protected system may choose to include in an auth check | becoming the PDP, registering resources, final allow/deny |
+| `flex-auth` | resource authorization policy, decision logs, protected-system registry | live allow/deny decisions, decision explanations, policy version, decision-rate anomalies | risk context or posture hints that a protected system may choose to include in an auth check | becoming the PDP, registering resources, final allow/deny |
 | `secrets-engine` | approved secret workflow and scoped capability delivery | metadata-only records of reads, leases, deliveries, rotations, revocations | posture hints about abnormal secret-use patterns or repeated denied delivery attempts | holding secret values, issuing leases, bypassing approval |
-| OpenBao **(Tooling — reach via `secrets-engine`)** | runtime secret custody, secret engines, dynamic credentials | engine/mount metadata, lease/revocation evidence, platform-secret posture | posture hints for secret-authority consumers or operators | root-token custody, secret-engine configuration ownership |
+| `railiance-platform` / OpenBao | runtime secret custody, secret engines, dynamic credentials | engine/mount metadata, lease/revocation evidence, platform-secret posture | posture hints for secret-authority consumers or operators | root-token custody, secret-engine configuration ownership |
 | `ops-warden` | operational SSH certificate issuance and routing guidance | signing attempts, TTL/principal anomalies, access-routing misuse evidence | sign-request posture hints, actor-scrutiny hints, metadata-only evidence requests | issuing certificates, routing non-SSH credentials, host trust config |
-| Railiance runtime layers **(reach via the owning engine)** | provisioning, deployment, isolation, workload lifecycle | deployment provenance, runtime health, workload/network/storage events, recovery outcomes | bounded requests for isolate, rebuild, or validate, always within the runtime's own authority | becoming the deployment repo or cluster operator |
+| Railiance runtime layers | provisioning, deployment, isolation, workload lifecycle | deployment provenance, runtime health, workload/network/storage events, recovery outcomes | bounded requests for isolate, rebuild, or validate, always within the runtime's own authority | becoming the deployment repo or cluster operator |
 | Governed domain assistants (example: `qonto-assistant`) | service-local business logic, service-local fast loops, customer/domain-facing policy enforcement points | audit events, policy denies, local safety loop outcomes, service-owned genome records | service-local posture hints and metadata-only evidence requests | replacing local policy kernels or business logic |
 | `state-hub` | live coordination state and work-record indexing | repo/workplan/task/progress metadata, incident references | non-secret progress events, posture evidence, incident notes | becoming canon, storing secret payloads, driving irreversible response |
@ -61,7 +54,7 @@ explicitly in the boundary model:
 - and it already emits an audit stream and operates a local fast loop.
 That class of system is not identical to a generic workload behind
-`access-engine`, and it is not infrastructure either.
+`flex-auth`, and it is not an infrastructure control plane either.
 `kings-guard`'s relationship to this class is:
@ -82,19 +75,3 @@ pattern:
  control paths
 See `docs/pilots/QontoAssistantPosturePilot.md`.
 The pilot lane is chosen partly *because* it is layer-clean: `qonto-assistant`
 publishes its own audit stream and genome record, so kings-guard needs no
 Tooling client to run it. The `key-cape`, OpenBao and runtime rows above stay
 fixture-driven until the engine surfaces named in `INTENT.md` §*Declared engine
 gaps* exist.
 ## 6. Layer conformance
 Mechanically checkable, per layer model §10:
 - `pyproject.toml` declares **zero runtime dependencies** — no database driver,
  no OpenBao client, no Kubernetes client;
 - every `EffectorRequest` carries an explicit `authority_boundary`, and the
  values in use are `advisory_only` and `metadata_only`;
 - no module exposes an authorization decision surface.
--- a/intakes/intakes.md
+++ b/intakes/intakes.md
@ -7,9 +7,7 @@ id: KG-IN-0001
 kind: intake
 title: 'Assent requested: Staff layer placement, control-plane vocabulary, and the
  posture asymmetry'
-status: closed
+status: open
 outcome: absorbed
 promoted_to: KG-DEC-2026-001
 origin: cross-repo
 origin_ref: gate-house GH-DEC-2026-001
 priority: medium
@ -32,38 +30,4 @@ description: 'gate-house asks kings-guard to assent to its placement in the NetK
  that should change the doctrine rather than be worked around.'
 created: '2026-08-28T19:30:17.201213Z'
 updated: '2026-08-28T19:30:17.201213Z'
 closed: '2026-08-28'
 resolution: 'Assent with finding. All three points assented and adopted in
  INTENT.md, SCOPE.md, README.md, AGENTS.md, and docs/AdjacentSystemBoundary.md.
  The invited challenge to the binding rule was taken up and answered: do not
  weaken section 5 — but section 4 catalogs kings-guard as owning containment
  while no engine exposes a containment surface, so the charter is currently
  undischargeable. Two rulings requested of gate-house. Full record:
  decisions/decisions.md KG-DEC-2026-001. Vocabulary sweep of the architecture
  spec handed off as KG-IN-0002.'
 ```
 ## KG-IN-0002 — Sweep "control plane" and layer vocabulary through NetKingdomImmuneArchitecture.md
 ```yaml
 id: KG-IN-0002
 kind: intake
 title: Sweep "control plane" and layer vocabulary through NetKingdomImmuneArchitecture.md
 status: open
 origin: residual
 origin_ref: KG-DEC-2026-001
 priority: low
 owner: kings-guard
 standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
 description: 'specs/NetKingdomImmuneArchitecture.md (approx. 1900 lines) predates the
  NetKingdom Security Layer Model and uses "control plane" in several places —
  including a "Platform Immune Control Plane" subgraph — where the layer model
  reserves that vocabulary for the Engine layer. A scoping note now sits at the head
  of the document so no reading takes it as a kings-guard self-description, but the
  body is not adapted. Sweep it: separate the components that are engine-layer
  authorities from the observation-and-judgment surface kings-guard actually owns,
  and check that no part of the architecture places a decision point in Staff
  (layer model section 6).'
 created: '2026-08-28'
 updated: '2026-08-28'
 ```
--- a/specs/NetKingdomImmuneArchitecture.md
+++ b/specs/NetKingdomImmuneArchitecture.md
@ -14,16 +14,6 @@ classification: Public
 # NetKingdom Immune Architecture
 > **Layer note (2026-08-28).** kings-guard is a **Staff**-layer repository
 > under the NetKingdom Security Layer Model v0.1 (assented in
 > `decisions/decisions.md` KG-DEC-2026-001). Where this document uses "control
 > plane", read it as naming an **estate-wide, Engine-layer** arrangement of
 > deterministic authorities — never as a self-description of `kings-guard`,
 > which publishes posture and requests bounded response through engine APIs.
 > The parts of this architecture that render decisions or hold state belong to
 > engines; kings-guard owns observation, judgment, and the request. A full
 > vocabulary sweep of this document is tracked as intake KG-IN-0002.
 ## 1. Purpose
 This document defines the reference architecture for **Kings Guard Security**, implemented in the `kings-guard` repository and positioned within the wider **NetKingdom** ecosystem.