kings-guard/SCOPE.md
tegwick 97c7eea1da Align with Security Layer Model v0.7; review scope vs intent; open KG-WP-0003
The standard is accepted at v0.7 with a working companion. v0.7 wrote the
§3.4 agent-principal rules that v0.6 announced and never wrote — our
finding — and credits kings-guard for it. Our other two findings landed
too: the actuation row is no longer attributed to us, and §17 records
kings-guard as drafter of the emission-cadence declaration.

INTENT.md now carries the declaration in frontmatter (layer: Staff,
conformance_state: blocked-clean) as the companion asks, plus prose in
our own voice. Adopted: the four agent-principal rules; the evidence
doctrine and our obligations under it; containment reframed as proposal
throughout. Direction of Evolution stage 3 rewritten — it described
integrating with effectors to actuate, which §9.2 forbids — and stage 5
now carries the constraint that federated memory may not become a state
plane.

SCOPE.md gains evidence classification, the cadence draft, and
stream-completeness judgment as in-scope; actuation, standing
credentials, and becoming a state plane as explicitly out.

history/2026-08-29-layer-model-v0.7-scope-intent-review.md assesses the
adapted documents against the implementation. The finding: the documents
are now correct and the code has not caught up. Nine gaps, G1-G8 carried
by KG-WP-0003, G9 remaining as KG-IN-0002.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UEtvmYUBP2fDtirJGWn5MW

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014379@bnt-lap001
Assistant-Session: 4af9e20f-1768-4afc-951b-b507784e382b
2026-08-29 14:42:34 +02:00

4.8 KiB

SCOPE

Lightweight boundary for agents and contributors.


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.6.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.
  • layer.yaml, scripts/check_layer_conformance.py and tests/test_layer_conformance.py make the no-Tooling-client claim executable; the companion cites them estate-wide as the reference for a repository with no Tooling contacts at all.
  • Every input is still a fixture. No real emitted event has reached the evaluator, so statute §12's fourth step remains unstaffed. Closing that is KG-WP-0003.

Getting Oriented

  • Start with: INTENT.md
  • Architecture draft: specs/NetKingdomImmuneArchitecture.md
  • Exploration notes: history/InitialExploration.md
  • Agent instructions: AGENTS.md
  • Workplans: workplans/