tegwick
494ed02db3
Close the residual intake and open a ready workplan to re-home NetKingdomImmuneArchitecture.md onto Staff / Engine / Tooling, including the §9.2 containment correction. Assistant: grok Assistant-Session: 01a05ef1-9e5a-70f2-b0ff-0b05d6b38ae9
125 lines
6.6 KiB
Markdown
125 lines
6.6 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: closed
|
|
outcome: promoted
|
|
promoted_to: KG-WP-0004
|
|
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-09-02'
|
|
closed: '2026-09-02'
|
|
resolution: 'Promoted to KG-WP-0004. The architecture spec still predates the
|
|
layer model; the workplan carries the sweep, including the §9.2 containment
|
|
correction that G9 of the 2026-08-29 review added to this residual.'
|
|
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"
|
|
```
|