kings-guard/intakes/intakes.md

Intake records

KG-IN-0004 — Admit the shipped secrets-engine secret-use snapshot as observation input

id: KG-IN-0004
kind: intake
title: Admit the shipped secrets-engine secret-use snapshot as observation input
status: closed
outcome: promoted
promoted_to: KG-WP-0006
closed: '2026-09-05'
origin: cross-repo
origin_ref: SECRETS-WP-0008-T05
priority: medium
owner: kings-guard
requested_by: secrets-engine
description: >
  secrets-engine has shipped `secrets-engine secret-use snapshot [--catalog-id
  ID] [--json]` as a read-only Engine / Lifecycle surface over non-secret local
  evidence and catalog metadata. The envelope explicitly denies completeness,
  omits evidence-derived fields when no record exists, and declares a 1d
  heartbeat through `secrets-engine evidence heartbeat`. Review and admit the
  surface as an immune-observation input without adding a Tooling client,
  treating omission as non-occurrence, or treating readiness or decision ids
  as cached authorization. Define the lane-row mapping, cadence translation,
  stale-snapshot behavior, and tests before changing the secret-observation
  capability from pending.
created: '2026-09-04'
updated: '2026-09-05'

KG-IN-0001 — Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry

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

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)

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"

KG-IN-0005 — Source evidence needed for secret-abuse posture

id: KG-IN-0005
kind: intake
title: Source evidence needed for secret-abuse posture
status: open
origin: residual
origin_ref: KG-WP-0006
priority: medium
owner: kings-guard
requested_by: kings-guard
related:
- SECRETS-WP-0008-T05
- KG-IN-0004
description: >
  Snapshot parsing is admitted, but the secrets-engine envelope combines
  historical fields without their event timestamps, actors or record provenance.
  Obtain an Engine-owned event/provenance contract and explicit evidence-class
  bindings, scoped heartbeat assertions and reconciliation evidence, plus an
  authorized deployment capture. Review those inputs before enabling secret-abuse
  posture. Keep snapshot completeness unknown and never infer allow/deny from
  readiness, lifecycle metadata or decision ids. No direct Tooling contact.
created: '2026-09-05'
updated: '2026-09-05'

KG-IN-0006 — Review requested: security layer model v0.8 (§9.5 boundary, §12 step four)

id: KG-IN-0006
kind: intake
title: 'Review requested: security layer model v0.8 (§9.5 boundary, §12 step four)'
status: closed
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.8 (net-kingdom@66eeaba)
outcome: promoted
promoted_to: KG-DEC-2026-004
priority: medium
owner: kings-guard
requested_by: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
description: >
  gate-house cut security-layer-model v0.8 as proposed and circulated it for
  review as text. §9.5 carries kings-guard's recomputability boundary
  (GH-DEC-2026-007) together with a criteria-grounding clause gate-house added:
  a criterion MUST bottom out in evidence about the subject, not another party's
  conclusion about it. gate-house asked kings-guard to attack that clause, naming
  the reversal falsifier — a legitimate maturity criterion that cannot be
  expressed without dereferencing a judgment, with human-attested controls as the
  likely candidates. §12 step four is unchanged and gate-house asked whether the
  qonto-assistant pilot has gone live, in which case the paragraph needs
  correcting in this version rather than the next. §11 gains the
  emission-guarantee declaration, flagged to kings-guard as the cadence consumer.
created: '2026-09-06'
updated: '2026-09-21'
closed: '2026-09-21'
resolution: >
  Assent to §9.5 at v0.8, scoped to the boundary at net-kingdom@66eeaba and not
  to v0.8 as a whole; the added grounding clause is assented and the falsifier was
  attacked against the two real candidates this repository holds, and did not
  fire. Four findings returned: a companion reading for attestation-grounded
  criteria; §12 step four's normative sentence stands but its supporting sentence
  has drifted in kings-guard's favour and a narrower wording is proposed; §11
  declaration-form precedence left to gate-house (KG-IN-0007); §11 emission
  guarantee for published posture left open rather than resolved in our own favour
  (KG-IN-0008). Commentary: docs/StatuteV08Review.md (KG-COM-0002). Decision:
  KG-DEC-2026-004. Reply three weeks late; the delay is kings-guard's.

KG-IN-0007 — §11 declaration-form precedence and case sensitivity

id: KG-IN-0007
kind: intake
title: §11 declaration-form precedence and case sensitivity
status: open
origin: cross-repo
origin_ref: flex-auth FLEX-WP-0030 boundaries-review B1 (corrected 2026-09-21)
priority: medium
owner: kings-guard
requested_by: flex-auth
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
blocked_on: gate-house ruling on §11 precedence and §3 case sensitivity
related:
- KG-DEC-2026-004
- KG-DEC-2026-001
description: >
  kings-guard carries both forms §11 permits and they state different values:
  INTENT.md declares `Staff`, layer.yaml declares `staff`. §11 does not say which
  governs when both are present, so two conformance runs reach different answers
  about this repository and both follow the standard. flex-auth withdrew its
  earlier cross-repository casing claim and is not asking anyone to align.
  kings-guard is NOT changing either file: picking a form would be this
  repository authoring a ruling gate-house holds, on the one section saying a
  layer stated by anyone other than the repository itself is not a declaration,
  and a guess would be invisible to the ruling. Two rulings are needed — which
  form governs, and whether the §3 vocabulary is case-sensitive. Also folded in:
  whether a declaration may carry a standard version (flex-auth B4). kings-guard's
  layer.yaml carries `standard_version: "0.7"`, read locally as provenance for the
  version the conformance script was checked against rather than as the version of
  an assent; the field means two things and the statute does not say which. When
  the rulings land, align both files and the version field in one commit.
  Position and argument: docs/StatuteV08Review.md F3 and F4.
created: '2026-09-21'
updated: '2026-09-21'

KG-IN-0008 — Is published posture §4 evidence, and does kings-guard owe an emission guarantee?

id: KG-IN-0008
kind: intake
title: Is published posture §4 evidence, and does kings-guard owe an emission guarantee?
status: open
origin: residual
origin_ref: KG-DEC-2026-004
priority: medium
owner: kings-guard
requested_by: kings-guard
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
blocked_on: gate-house ruling on whether published posture is a §4 source of evidence
related:
- KG-IN-0006
- KG-WP-0003
description: >
  v0.8 §11 requires every repository catalogued in §4 as a source of evidence to
  declare its emission guarantee in its machine-readable layer declaration, and
  says a source declaring none is not conforming. kings-guard's §4 row catalogues
  adaptive defence, judgment and observation — not evidence production — and
  gate-house flagged the new check to kings-guard as the cadence CONSUMER. On that
  reading kings-guard owes nothing and layer.yaml is conforming as it stands.
  kings-guard declines to rest on the reading that favours it: kings-guard
  publishes posture, gate-house consumes it for authority meaning and
  access-engine renders it, and whether that makes published posture §4 evidence
  is not settled by the catalog row. Same shape as flex-auth's open G2 over the
  decision record. If gate-house rules that posture is §4 evidence, kings-guard
  owes an emission guarantee for the posture stream — expected class attributive,
  since posture is a judgment and no completeness is claimed — and will declare
  one in layer.yaml. Argument: docs/StatuteV08Review.md F5.
created: '2026-09-21'
updated: '2026-09-21'