tegwick
4b37bb18a5
gate-house asked kings-guard to check the posture/maturity boundary, with the concern that a second grading authority would be the same shape of mistake as a second decision point. Its proposed line was volatile current state against slow progression. Answered with a proposed revision, KG-DEC-2026-002, argued in docs/PostureMaturityBoundary.md (KG-COM-0001). Volatility is an observation about data, not a definition. It fails at both edges and, more importantly, describes the two things without partitioning them — every case left 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 calls that determinism the thing that makes it an Engine; §3.3 makes inference Staff by construction. So: recompute against the same criteria and evidence — must get the same answer, it is maturity and belongs in an engine; cannot promise the same answer, it is posture and belongs in Staff. It is one rule read from both sides. §9.5 already says a criterion that cannot be evaluated by rule is not yet a criterion; the mirror is that a judgment that can be evaluated by rule is not posture but a criterion in the wrong repository. kings-guard accepts the constraint this puts on its own side: capability readiness is not an input to posture, since feeding a deterministic value into a non-deterministic one would blur the boundary from our door. That also answers the incident-dependency half of the intake. 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
119 lines
6.3 KiB
Markdown
119 lines
6.3 KiB
Markdown
# Intake records
|
|
|
|
## KG-IN-0001 — Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry
|
|
|
|
```yaml
|
|
id: KG-IN-0001
|
|
kind: intake
|
|
title: 'Assent requested: Staff layer placement, control-plane vocabulary, and the
|
|
posture asymmetry'
|
|
status: closed
|
|
outcome: absorbed
|
|
promoted_to: KG-DEC-2026-001
|
|
origin: cross-repo
|
|
origin_ref: gate-house GH-DEC-2026-001
|
|
priority: medium
|
|
owner: kings-guard
|
|
requested_by: gate-house
|
|
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
|
|
description: 'gate-house asks kings-guard to assent to its placement in the NetKingdom
|
|
security layer model. (1) kings-guard is Staff — agentic and non-deterministic —
|
|
not an Engine. Acting at runtime does not make a repository an Engine; being agentic
|
|
makes it Staff. (2) Consequently its self-description as an adaptive security control
|
|
plane needs revisiting: control plane is Engine-layer vocabulary (standard section
|
|
8). This is not a demotion — it is the reason kings-guard may contain a threat only
|
|
by calling an engine, never by reaching into OpenBao or a cluster directly (the
|
|
binding rule, standard section 5: Staff never touches Tooling directly). (3) The
|
|
posture contract with gate-house and its asymmetry: adaptive systems may reduce
|
|
authority, require step-up, or request containment; they must never probabilistically
|
|
manufacture additional authority. kings-guard publishes posture, gate-house defines
|
|
its authority meaning, access-engine renders it. If the binding rule is impractical
|
|
for containment in a real incident, say so — that is exactly the kind of finding
|
|
that should change the doctrine rather than be worked around.'
|
|
created: '2026-08-28T19:30:17.201213Z'
|
|
updated: '2026-08-28T19:30:17.201213Z'
|
|
closed: '2026-08-28'
|
|
resolution: 'Assent with finding. All three points assented and adopted in
|
|
INTENT.md, SCOPE.md, README.md, AGENTS.md, and docs/AdjacentSystemBoundary.md.
|
|
The invited challenge to the binding rule was taken up and answered: do not
|
|
weaken section 5 — but section 4 catalogs kings-guard as owning containment
|
|
while no engine exposes a containment surface, so the charter is currently
|
|
undischargeable. Two rulings requested of gate-house. Full record:
|
|
decisions/decisions.md KG-DEC-2026-001. Vocabulary sweep of the architecture
|
|
spec handed off as KG-IN-0002.'
|
|
state_hub_intake_id: "01a049ea-2e37-7dde-9772-fab7e788d8d7"
|
|
```
|
|
|
|
## KG-IN-0002 — Sweep "control plane" and layer vocabulary through NetKingdomImmuneArchitecture.md
|
|
|
|
```yaml
|
|
id: KG-IN-0002
|
|
kind: intake
|
|
title: Sweep "control plane" and layer vocabulary through NetKingdomImmuneArchitecture.md
|
|
status: open
|
|
origin: residual
|
|
origin_ref: KG-DEC-2026-001
|
|
priority: low
|
|
owner: kings-guard
|
|
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
|
|
description: 'specs/NetKingdomImmuneArchitecture.md (approx. 1900 lines) predates the
|
|
NetKingdom Security Layer Model and uses "control plane" in several places —
|
|
including a "Platform Immune Control Plane" subgraph — where the layer model
|
|
reserves that vocabulary for the Engine layer. A scoping note now sits at the head
|
|
of the document so no reading takes it as a kings-guard self-description, but the
|
|
body is not adapted. Sweep it: separate the components that are engine-layer
|
|
authorities from the observation-and-judgment surface kings-guard actually owns,
|
|
and check that no part of the architecture places a decision point in Staff
|
|
(layer model section 6).'
|
|
created: '2026-08-28'
|
|
updated: '2026-08-28'
|
|
state_hub_intake_id: "01a049ea-3a04-74b9-a9b1-e2630f8d5628"
|
|
```
|
|
|
|
## KG-IN-0003 — Review requested: security layer model v0.3 (maturity-engine, and the posture/maturity boundary)
|
|
|
|
```yaml
|
|
id: KG-IN-0003
|
|
kind: intake
|
|
title: 'Review requested: security layer model v0.3 (maturity-engine, and the posture/maturity
|
|
boundary)'
|
|
status: closed
|
|
origin: cross-repo
|
|
origin_ref: net-kingdom security-layer-model_v0.3
|
|
outcome: promoted
|
|
promoted_to: KG-DEC-2026-002
|
|
priority: medium
|
|
owner: kings-guard
|
|
requested_by: gate-house
|
|
description: 'v0.3 is proposed and changes sections 4, 9 and 13 only; the v0.2 assent
|
|
record stands. It responds directly to KG-DEC-2026-001. Section 9.5 assigns graded
|
|
progression to a new maturity-engine, which now owns the gap register with intended_owner,
|
|
blocked_on and review dates, and capability readiness — so your three declared engine
|
|
gaps and the pending containment claim become queryable facts rather than footnotes
|
|
in a standard. Your finding also produced 9.1 in v0.2, and v0.3 applies it to gate-house
|
|
itself: gate-house was catalogued as owning conformance review with no engine to
|
|
act through, exactly the defect you named for containment, and it now acts through
|
|
maturity-engine. THE QUESTION FOR YOU is a boundary we have not drawn: posture and
|
|
maturity are both graded, and we do not want two engines grading the same subject.
|
|
Our reading is that posture is volatile current security state about an actor, published
|
|
by kings-guard and rendered by access-engine, while maturity is slow progression
|
|
of a capability against declared criteria. If that line is wrong, or if maturity-engine
|
|
would absorb something you consider posture, say so now — a second grading authority
|
|
would be the same shape of mistake as a second decision point. Also worth your view:
|
|
does capability readiness for containment belong in maturity-engine, or does tracking
|
|
your own gaps there create a dependency you would rather not carry during an incident?
|
|
Assent, revision, or rejection acceptable.'
|
|
created: '2026-08-28T20:40:12.260389Z'
|
|
updated: '2026-08-28T20:40:12.260389Z'
|
|
closed: '2026-08-29'
|
|
resolution: 'Answered with a proposed revision. The boundary is recomputability,
|
|
not volatility: given the same criteria and the same evidence, if you must get
|
|
the same answer it is maturity and belongs in an engine, and if you cannot
|
|
promise the same answer it is posture and belongs in Staff. Drawn from statute
|
|
section 9.5 and section 3.3 rather than imposed on them, and it partitions
|
|
where volatile-versus-slow only describes. kings-guard accepts the constraint
|
|
this puts on its own side: capability readiness is not an input to posture,
|
|
which also answers the incident-dependency question. Commentary:
|
|
docs/PostureMaturityBoundary.md. Decision: KG-DEC-2026-002.'
|
|
state_hub_intake_id: "01a04d8d-66f8-70ef-b2b5-1eff03569471"
|
|
```
|