kings-guard/decisions/decisions.md

# 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
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

```yaml
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`.

## KG-DEC-2026-003 — Admit scoped snapshots without claiming event completeness

```yaml
id: KG-DEC-2026-003
kind: decision
title: Admit scoped snapshots without claiming event completeness
status: resolved
owner: codex
repo: kings-guard
origin_ref: KG-WP-0006
created: '2026-09-05'
updated: '2026-09-05'
decided_by: codex
state_hub_decision_id: "200e63b3-973a-4e3d-a687-3da0949bdcb6"
```

Consume secrets-engine snapshots through a pure typed adapter with caller-owned
catalog-to-tenant/subject bindings. Preserve omitted evidence as unknown and
assess only snapshot freshness. The source merges independently selected
historical fields without event timestamps or actors, so do not synthesize an
authorization event or infer current secret-abuse posture. Completeness stays
unknown; decision ids and session handles are not retained. Source provenance
and operational evidence are handed off as KG-IN-0005.

Consume InfoTechCanon standard/emission-cadence 0.1 in the Qonto fixtures;
NetKingdom security fields and local provenance are namespaced extensions.
The handover draft remains historical and NK-WP-0035 profile adoption stays
with its owner. Deployed Qonto validation remains KG-WP-0005-T03.