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

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

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

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'
state_hub_decision_id: "94e2af0f-cce5-4bf0-9cdb-48181246e7f5"

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.