kings-guard/SCOPE.md

# SCOPE

> Lightweight boundary for agents and contributors.

---

## Layer

**Staff** — interactive, non-deterministic; adaptive defence, observation, and
judgment. Kings-guard proposes containment but does not own or perform it.
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.7.md`.

---

## One-liner

Adaptive security assessment and bounded-response layer for multi-tenant cloud
platforms.

---

## Core Idea

`kings-guard` turns declared healthy intent plus observed runtime behavior into
posture judgments, typed security signals, and bounded response **requests**. It
consumes evidence without replacing any system's primary authority, and it
actuates nothing: containment is rendered by an Engine and enforced by a PEP
(statute §9.2).

The one-line test for anything proposed here: **does it judge and propose, or
does it decide and act?** The first is in scope. The second is another layer's.

---

## In Scope

- Canonical terminology and contracts for security genome, phenotype,
  observation, signal, effector, tolerance, inflammation, and immune memory.
- **Evidence classification** — marking each consumed stream load-bearing or
  attributive (§9.6), since the obligations differ.
- **The emission-cadence declaration draft** (§17). kings-guard is its only
  consumer and drafts it; Taxonomy owns it. Includes the reconciliation or
  heartbeat form required for low-volume load-bearing classes, where rate
  monitoring cannot work.
- **Stream-completeness judgment** — treating silence as a signal, and carrying
  the resulting doubt in the posture output rather than reporting confidence in
  a stream that may be incomplete.
- Reference architecture and boundary documents for adaptive defense in
  multi-tenant and agent-active environments.
- Minimal posture-evaluation loop design: ingest observations, compare against
  intended healthy state, and emit typed posture/signal results.
- Integration seams to adjacent security systems, taken **through the owning
  engine**: `access-engine` (the decision point, currently named `flex-auth`),
  `secrets-engine`, `user-engine`, `audit-core`, and the Railiance runtime
  layers. `key-cape` and OpenBao are Tooling and are never contacted directly.
- Non-secret evidence, workplans, and repo-operational metadata.

---

## Out of Scope

- **Actuation of any kind.** Reduce authority, require step-up, isolate a
  workload — these are authority-changing operations rendered by an Engine and
  enforced by a PEP. kings-guard proposes them and never performs them, even
  when no engine surface exists to receive the proposal.
- **Holding a standing credential** (§3.4 rule 1).
- **Becoming a state plane for another layer**, immune memory included
  (§3.4 rule 3). Immune memory informs kings-guard's judgment and may be
  published as evidence; nothing may depend on it at runtime.
- 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.
- Claiming that an event's absence from an archive proves it did not happen, or
  that a quiet stream is a healthy one (§9.6).
- 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
  operations.
- Generic SIEM ownership, ticket tracking, or live work coordination beyond
  this repo's own workplans.

---

## Current State

- Canon now includes `specs/ImmuneContracts.md`,
  `docs/AdjacentSystemBoundary.md`, and
  `docs/pilots/QontoAssistantPosturePilot.md`.
- 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
  service and will not become one.
- Evidence class, stream-completeness evaluation, origin-linked proposals, and
  the emission-cadence Taxonomy draft landed in `KG-WP-0003`.
- `layer.yaml`, `scripts/check_layer_conformance.py` and
  `tests/test_layer_conformance.py` make the no-Tooling-client claim and the
  no-standing-credential claim executable; the companion cites them estate-wide
  as the reference for a repository with no Tooling contacts at all.
- Live observation of `qonto-assistant` uses the source's own AuditLogger emit
  path. The hand-built fixture is retained as a regression case. The local
  contract proof now consumes the source-owned cadence declaration and checks
  heartbeat, sequence, and reconciliation evidence for the load-bearing deny
  class. Validation against a deployed stream remains operational work.
- Engine secret-use snapshots have a pure, scoped metadata adapter with explicit
  unknown completeness and snapshot freshness findings. Event-based secret-abuse
  posture awaits source provenance and operational evidence (`KG-IN-0005`). See
  `docs/SecretUseSnapshotAdmission.md`.
- Cadence fixtures consume InfoTechCanon `standard/emission-cadence` 0.1;
  the local handover draft is historical and NetKingdom profile adoption remains
  with its owner.
- `specs/NetKingdomImmuneArchitecture.md` was swept under `KG-WP-0004` onto
  Staff / Engine / Tooling (v0.7). It is an estate map; this repository
  implements the Staff slice only. Containment is proposed, not performed.
  Immune memory is not a state plane.

---

## Getting Oriented

- Start with: `INTENT.md`
- Architecture (estate map, layer-swept): `specs/NetKingdomImmuneArchitecture.md`
- Exploration notes: `history/InitialExploration.md`
- Agent instructions: `AGENTS.md`
- Workplans: `workplans/`