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
state_hub_decision_id: "c082580f-7aef-4c02-ad08-dfe971bafee7"
```

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

## KG-DEC-2026-004 — Assent to §9.5 at v0.8, including the grounding clause kings-guard did not propose

```yaml
id: KG-DEC-2026-004
kind: decision
title: Assent to §9.5 at v0.8, including the grounding clause kings-guard did not
  propose
status: resolved
owner: codex
repo: kings-guard
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
standard_commit: net-kingdom@66eeaba
origin_ref: KG-IN-0006
commentary: docs/StatuteV08Review.md
related:
- gate-house GH-DEC-2026-007
- gate-house GH-WP-0003-T04
- KG-DEC-2026-002
affects:
- kings-guard
- gate-house
- maturity-engine
- net-kingdom
created: '2026-09-21'
updated: '2026-09-21'
decided_by: codex
disposition: assent-with-findings
state_hub_decision_id: "dcff47fc-c4a3-4c31-a496-dad1e9c26e58"
```

## Context

`gate-house` adopted `KG-DEC-2026-002` as `GH-DEC-2026-007` and added a clause
`kings-guard` did not propose, then cut it into statute v0.8 §9.5 and circulated
v0.8 for assent, asking `kings-guard` to attack the added clause and to say
whether §12's step four is still true.

## Decision

**Assent, with four findings returned. Scope is stated rather than inferred.**

### The added clause is assented

> A criterion MUST bottom out in evidence about the subject, not in another
> party's conclusion about the subject.

It closes a hole in the test `kings-guard` proposed rather than enlarging it:
recomputability is assessed over stated criteria, so a criterion dereferencing a
verdict recomputes perfectly and has still installed a second grading authority
— the failure consequence 2 claims is structurally prevented. We would rather be
held to a test that catches the circumvention than trusted not to attempt it.

**The falsifier gate-house wrote into the reversal does not fire.** Tested
against the two real candidates this repository holds: a §3.4 rule whose check is
an assertion (`tool_use_shapes`), and a readiness row grounded on another
repository's decision (`owner_status: access-engine declined`). Both resolve the
way gate-house predicted — grade the attestation event's existence, freshness and
issuer, never its verdict. We hold no criterion that cannot be expressed without
dereferencing a judgment. Argument: `docs/StatuteV08Review.md` F1.

### What the assent covers

- The boundary in **§9.5** as it stands at `net-kingdom@66eeaba`, including the
  grounding clause, all three consequences, and the stated §17 limit.
- Given **at a named version, not to current text** (§14). Revision of §9.5
  reopens it; revision elsewhere in v0.8 does not.
- **Not assent to v0.8 as a whole, and it does not dispose of §11.** §9.5 does
  not depend on the §11 declaration-form questions, so it need not wait on them;
  the round being held open over §11 should not be read as §9.5 unsettled.

## Findings returned

1. **§9.5 companion reading (F1).** A criterion grounded on an attestation event
   grades the attestation, not the property attested. A consumer reading the
   resulting level as the property commits the §9.6 error one layer up, inside a
   ladder. Where that belongs — statute or `maturity-engine` ladder guidance — is
   gate-house's call.
2. **§12 step four (F2).** The normative sentence stands: `kings-guard` has still
   never observed anything in production, and `KG-WP-0005-T03` waits on the
   runtime owner. The supporting sentence has drifted in our favour — since v0.6,
   `KG-WP-0005-T02` drives `qonto-assistant`'s real `AuditLogger` emit path, so
   "every input is a hand-built fixture" is no longer exact. Narrower wording
   proposed; correction belongs in this version.
3. **§11 declaration form (F3).** `kings-guard` carries both permitted forms and
   they differ by case. Neither file is being changed until gate-house rules
   precedence and case sensitivity — `KG-IN-0007`.
4. **§11 emission guarantee (F5).** `kings-guard` declines the catalog reading
   that exempts it. Whether published posture is §4 evidence is unruled, and the
   repository that benefits from the narrow reading should not settle it —
   `KG-IN-0008`.

## Consequences

- Consequence 3 of §9.5 — capability readiness MUST NOT be an input to posture —
  is normative on this repository. We volunteered it and do not want it softened.
- Ladder criteria over `kings-guard` may ground on our `layer.yaml` attestations;
  levels so computed grade declaration hygiene and MUST NOT be reported as the
  §3.4 properties holding.
- `layer.yaml` is not edited by this decision. Its `standard_version: "0.7"`
  stays pending the B4 ruling (`KG-IN-0007`, commentary F4).
  *Superseded 2026-09-21:* B4 was ruled in `GH-DEC-2026-017` §5 and the field was
  removed under `KG-IN-0007`; the validated-against version now lives in
  `scripts/check_layer_conformance.py` (`VALIDATED_AGAINST`).

## KG-DEC-2026-005 — Apply GH-DEC-2026-020 to the checker; assent to A9, A10, A11 and A13, and return A12 r2 with one finding

```yaml
id: KG-DEC-2026-005
kind: decision
title: Apply GH-DEC-2026-020 to the checker; assent to A9, A10, A11 and A13, and
  return A12 r2 with one finding
status: resolved
owner: codex
repo: kings-guard
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
source: gate-house docs/amendments/v0.8-section-11-declaration-amendments.md v0.2 (gate-house@104f3fc)
related:
- gate-house GH-DEC-2026-020
- gate-house GH-DEC-2026-017
- gate-house GH-WP-0004-T09
- KG-DEC-2026-004
affects:
- kings-guard
- gate-house
created: '2026-09-21'
updated: '2026-09-21'
decided_by: codex
disposition: 'A9 approved; A10 approved; A11 approved; A12 r2 revised; A13 approved'
```

## Context

`gate-house` circulated A9–A13 for assent (message `09a2d1cb`), then ruled what A12
reaches in `GH-DEC-2026-020` and re-circulated A12 as A12 r2 (message `54080f87`),
asking again because assent to A12 as first circulated does not carry over. Both were
read from gate-house's committed files at `104f3fc`, not from the messages; the ruling
and the message agree.

`GH-DEC-2026-020` §4 adopts this repository's `VALIDATED_AGAINST` constant as the
reference pattern and requires two changes of us: print the run's scope, and widen A12
detection from the key name `standard_version` to any version in any key or value.

## Applied

`scripts/check_layer_conformance.py` now prints `checking against:` and `scope:` as the
first two lines of **every** run, before anything can exit — including a malformed-
declaration failure — and the OK line carries both. A12 is enforced over every key and
value of the `INTENT.md` frontmatter and `layer.yaml`: any version key other than
`schema_version`, a versioned standard or companion path or file name, and any version
token in `standard:`, `companion:` or `framework:`. Comments are not read. Stance,
claims and classification maps are never read for A12; this repository has none.
Tests in `tests/test_layer_conformance.py` fail if a versioned `standard:` path or a
`companion_version` comes back.

Neither declaration form changed. Both were already clean under r2: `standard:` in
`INTENT.md` was de-versioned under `GH-DEC-2026-017`, and there is no companion version.

## Dispositions

- **A9 — approved.** The four-token closed vocabulary with a mandatory fold is what
  `KG-IN-0007` needed and what `GH-DEC-2026-017` §2 already governs here.
- **A10 — approved.** A marking rather than a reading is the right fix. Under it our §4
  row is *unassessed* until marked, and a run reports it so — which is the answer
  `KG-IN-0008` asked for: the repository that benefits from the narrow reading does not
  settle whether published posture is evidence.
- **A11 — approved.** One finding on wording, not substance: *"A run over §4 and a run
  over every repository carrying a declaration"* names two estate scopes. Our checker's
  run is a third, one repository, and prints so. The scope sentence should admit a
  single-repository run rather than leave it to read as neither.
- **A13 — approved.**
- **A12 r2 — revised, one finding.** *"No key or value of either carries a version of
  this standard"* reaches a revision **citation** in prose as literally as it reaches a
  pin. `layer.yaml` carries three: `v0.5` in a non-Tooling note, and `v0.6` twice in gap
  records (`owner_status: access-engine declined (v0.6 §13)`). They are provenance —
  where a ruling was made, in section numbering that has since moved — and are not
  readable as a validity condition, which is §5's ground. But the text as written reaches
  them, and an implementer who reads "any value" literally must fail them. Proposed
  addition: *"A version reached is one carried as a pin: a version key, or a version in a
  path, file name, or identity-bearing value naming this standard or its companion. A
  citation of an earlier revision in a record's prose is provenance and is not reached."*
  **kings-guard benefits from the narrower reading**, so it is not ours to settle. Until
  ruled, the checker reports each citation on every run as `NOTE (A12 r2 reach unruled)`
  and does not fail on it; if the wider reading is ruled, we reword the three values and
  the checker fails on them. We did not measure other repositories for the same shape.

## Consequences

- `VALIDATED_AGAINST` still names v0.7, the accepted text the checker was validated
  against. It moves when the checker is re-validated after the v0.8 flip, not before.
- The pre-existing ruff E501 at the no_standing_credential message in the checker is
  outside `make lint`'s scope and is not touched here.