kings-guard/decisions/decisions.md

Decision records

KG-DEC-2026-001 — Assent to Staff placement, release of control-plane vocabulary, and the posture asymmetry

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
state_hub_decision_id: "80313094-9b5d-4954-b37b-3313deac6b65"

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.

KG-DEC-2026-002 — The posture/maturity boundary is recomputability, not volatility

id: KG-DEC-2026-002
kind: decision
title: The posture/maturity boundary is recomputability, not volatility
status: resolved
owner: Bernd Worsch
repo: kings-guard
standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
origin_ref: KG-IN-0003
commentary: docs/PostureMaturityBoundary.md
affects:
- kings-guard
- gate-house
- maturity-engine
- net-kingdom
created: '2026-08-29'
updated: '2026-08-29'
decided_by: Bernd Worsch
disposition: revision-proposed

Context

gate-house asked kings-guard (KG-IN-0003) to check a boundary it had not drawn: posture and maturity are both graded, and two engines grading the same subject would be the same shape of mistake as a second decision point. Its proposed line was posture as volatile current state about an actor against maturity as slow progression of a capability.

Decision

Revision proposed. The line is nearly right and drawn on the wrong axis. Volatility is an observation about data, not a definition, and it fails at both edges — evidence can land in a burst, and a healthy subject can hold one posture for months. More importantly it describes the two things without partitioning them, and every case it leaves to argument is a route by which a second grading authority arrives.

The discriminator is already in the statute. §9.5 requires maturity to return the same level from the same criteria and evidence, and says that determinism is what makes it an Engine rather than an opinion; §3.3 says a repository whose core function is inference is Staff by construction. So:

Given the same criteria and the same evidence, recompute. If you must get the same answer, it is maturity and belongs in an engine. If you cannot promise the same answer, it is posture and belongs in Staff.

This is one rule read from both sides. §9.5 already states the maturity half — a criterion that cannot be evaluated by rule is not yet a criterion. The posture half is its mirror: a judgment that can be evaluated by rule is not posture, it is a criterion in the wrong repository. Together they partition; "volatile versus slow" does not.

Full argument: docs/PostureMaturityBoundary.md (KG-COM-0001).

Consequences accepted by kings-guard

• Capability readiness is not an input to posture. Readiness is deterministic and posture is not; feeding one into the other would make posture partly recomputable and blur the boundary from our side. Accepted as a constraint on this repository.
• Consequently, tracking our gaps in maturity-engine creates no incident-path dependency: we never consult our own readiness to judge an observation, so maturity-engine being unreachable mid-incident changes nothing about posture evaluation. This answers the second half of KG-IN-0003.
• Anything we currently call posture that proves recomputable belongs in maturity-engine as a criterion, and we will hand it over rather than keep it.

Limit

The test says "the same evidence", which is not yet well defined estate-wide. Until §17's schemas exist, two parties can disagree about whether they hold the same evidence and recomputability is a thought experiment rather than a check. §17 is therefore load-bearing for this decision; kings-guard owns the emission-cadence half under KG-WP-0003-T02.