coulomb/kings-guard
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Repoint at Security Layer Model v0.4; assess and report to gate-house

Browse source 
The standard moved v0.1 -> v0.4 after our assent. Reviewed; assent stands
unchanged. §9.1/§9.2/§9.3 adopt the KG-DEC-2026-001 finding and generalise
it estate-wide, and §12 now states that an unsatisfiability finding is a
success of the conformance loop.

Docs repointed at v0.4 (INTENT, SCOPE, AdjacentSystemBoundary, the
architecture spec note). KG-DEC-2026-001 still cites v0.1 deliberately —
it records what was assented to at the time.

INTENT gap table reshaped to §5.3's field names (capability,
intended_owner, blocked_on, review) so one register can hold both kinds,
with review dates set to 2026-11-28, and marked explicitly as unowned
capabilities rather than §5.3 declared contacts — kings-guard makes no
Tooling contact and is Conforming under §11.

Four findings sent to gate-house: §9.1 not carried through to the
observation claim; §13 conflating declared contacts with unowned
capabilities ahead of the maturity-engine migration; §9.6's unstated
consequence for posture (suppression biases posture optimistic and our
confidence score cannot express the doubt); and disclosure that §12's
fourth step is unstaffed while the pilot remains fixture-only.

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
This commit is contained in:
tegwick 2026-08-29 02:41:43 +02:00
parent bc1213545b
commit d99f395aa1
5 changed files with 132 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

31
INTENT.md
View file

@ -1,9 +1,16 @@
# INTENT
> **Layer: Staff.** *(NetKingdom Security Layer Model v0.1, §4 catalog —
> `net-kingdom/canon/standards/security-layer-model_v0.1.md`; ratified by
> `gate-house/decisions/decisions.md` GH-DEC-2026-001; assented here by
> `decisions/decisions.md` KG-DEC-2026-001 on 2026-08-28.)*
> **Layer: Staff.** *(NetKingdom Security Layer Model — current version
> `net-kingdom/canon/standards/security-layer-model_v0.4.md`, §4 catalog,
> status accepted; ratified by `gate-house/decisions/decisions.md`
> GH-DEC-2026-001; assented here by `decisions/decisions.md` KG-DEC-2026-001
> on 2026-08-28, against v0.1. This declaration is made in kings-guard's own
> voice, per §11.)*
>
> **Catalog entry (v0.4 §4):** adaptive defence, observation; **containment —
> pending (§9.2)**, until an engine exposes a containment surface. The pending
> mark exists because kings-guard raised the defect that v0.1 catalogued a
> capability §5 forbade discharging; the general rule is now §9.1.
>
> kings-guard is **interactive and non-deterministic**: adaptive defence,
> observation, containment. Acting at runtime does not make a repository an
@ -143,11 +150,17 @@ Capabilities kings-guard needs that no engine exposes today. Under the binding
rule these are gaps to close in the owning engine, not work to route around.
None is a standing licence to reach into Tooling.
| Gap | Needed for | Owning engine | Status |
| --- | --- | --- | --- |
| Authentication and assurance evidence (token assurance, attestation outcomes, authentication anomalies) exposed as an engine surface | identity-drift posture | `user-engine` / `access-engine` | open — no engine surface; kings-guard consumes fixtures only |
| Secret-use evidence (lease, revocation, mount and rotation metadata) exposed as an engine surface | secret-abuse posture | `secrets-engine` | open — no engine surface; kings-guard consumes fixtures only |
| A containment surface — reduce authority, require step-up, isolate a workload — callable as a deterministic engine API, and available while an incident is in progress | bounded response | `access-engine`, runtime engines | open — see KG-DEC-2026-001 §Finding |
These are **unowned capabilities**, not §5.3 declared contacts: kings-guard
makes no direct Tooling contact for any of them. Under §11 kings-guard is
**Conforming**, not a tracked non-conformance. The fields follow §5.3's shape so
one register can hold both, but the distinction is load-bearing — see the
assessment sent to gate-house on 2026-08-29.
| `capability` | Needed for | `intended_owner` | `blocked_on` | `review` |
| --- | --- | --- | --- | --- |
| Authentication and assurance evidence (token assurance, attestation outcomes, authentication anomalies) exposed as an engine surface | identity-drift posture | `user-engine` / `access-engine` | no engine surface exists; kings-guard consumes fixtures only | 2026-11-28 |
| Secret-use evidence (lease, revocation, mount and rotation metadata) exposed as an engine surface | secret-abuse posture | `secrets-engine` | no engine surface exists; kings-guard consumes fixtures only | 2026-11-28 |
| Containment surface — reduce authority, require step-up, isolate a workload — callable as a deterministic engine API, available while an incident is in progress | bounded response | `access-engine`, runtime engines | no engine surface exists; ruled pending in v0.4 §9.2, degraded-mode fallback ruled into the engine by §9.3 | 2026-11-28 |
Until a gap closes, the corresponding posture lane stays advisory and
fixture-driven. kings-guard MUST NOT open a direct path to the Tooling system