Implement KG-WP-0002 posture pilot scaffold

docs/AdjacentSystemBoundary.md

@@ -0,0 +1,77 @@
+---
+title: Kings Guard Adjacent-System Boundary
+version: 0.1.0
+status: Draft
+date: 2026-07-23
+repo: kings-guard
+classification: Public
+---
+
+# Kings Guard Adjacent-System Boundary
+
+## 1. Purpose
+
+This document records how `kings-guard` interacts with adjacent security and
+platform systems in the current NetKingdom stack.
+
+It exists to prevent overlap drift: `kings-guard` consumes evidence, evaluates
+posture, and emits bounded signals. It does not absorb the primary authority of
+identity, authorization, secret custody, or operations systems.
+
+## 2. Cross-System Rules
+
+The following rules apply to every integration below:
+
+1. `kings-guard` consumes **non-secret evidence** or references to secret
+   operations, never raw secret values.
+2. `kings-guard` contributes **risk and posture context**, never final
+   authorization or identity decisions.
+3. `kings-guard` emits **bounded signals and effector requests** that remain
+   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.
+
+## 3. System-by-System Boundary
+
+| Adjacent system | Primary authority | Evidence consumed by `kings-guard` | Signals returned by `kings-guard` | Non-goals |
+| --- | --- | --- | --- | --- |
+| `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 |
+| `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 |
+| `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 | 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 |
+
+## 4. Governed Domain Assistants
+
+`qonto-assistant` introduces an important pattern that deserves to be named
+explicitly in the boundary model:
+
+- it is a workload protected by the platform,
+- it is also a policy enforcement point in its own right,
+- 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
+`flex-auth`, and it is not an infrastructure control plane either.
+
+`kings-guard`'s relationship to this class is:
+
+- consume its service-local audit stream as `immune_observation`;
+- consume its declared healthy intent as `security_genome`;
+- emit posture hints that the service may adopt through its own local control
+  logic;
+- never take over its business logic, credentials, or final access policy.
+
+## 5. Current First-Class Integrations
+
+The first executable `kings-guard` slice targets one concrete adjacent-system
+pattern:
+
+- **Chosen pilot:** governed domain assistant (`qonto-assistant`)
+- **Why first:** already has a real genome record, audit stream, and fast local
+  loop; lets `kings-guard` validate contracts without waiting for new platform
+  control paths
+
+See `docs/pilots/QontoAssistantPosturePilot.md`.