The standard moved v0.4 -> v0.6. All four findings from our v0.4 review
were adopted in v0.5, and v0.6 went further on two of them.
§11 now requires a machine-readable declaration — prose cannot
distinguish a declaration from a transcribed review. We had none.
Added layer.yaml (form adapted from ops-warden's reference
implementation), scripts/check_layer_conformance.py, and
tests/test_layer_conformance.py.
The check makes our central claim mechanical rather than asserted: no
direct Tooling client in src/. The test exercises the negative case on a
synthetic tree, so it fails if the checker goes blind. pyyaml is added as
a DEV dependency only — `dependencies = []` is load-bearing for the §5
claim and stays empty.
Adopted from v0.6:
- containment is no longer ours (§9.2). Actuation is an Engine concept,
unowned and held at zero; kings-guard proposes containment and never
performs it. The register row is now a dependency, not our gap.
- observation is scoped to Staff-reachable sources, with identity and
secret observation pending — our finding 1, adopted near-verbatim.
- access-engine DECLINED the authentication-evidence gap; owner is now
the identity layer plus audit-core, reproposed and unassented.
- §11 blocked-clean recorded, with the rule that it must not rank below
conforming — our finding 2.
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
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
Answers gate-house intake KG-IN-0001 / GH-DEC-2026-001 against the
NetKingdom Security Layer Model v0.1.
Assent to all three points, recorded as KG-DEC-2026-001:
- kings-guard declares layer Staff in INTENT.md;
- "control plane" released to the Engine layer across INTENT, SCOPE,
README, AGENTS and the adjacent-system boundary;
- the posture asymmetry adopted as a repo invariant — already satisfied,
every EffectorRequest carries an explicit authority_boundary.
Boundary corrections: key-cape and OpenBao are Tooling, so their evidence
is routed through user-engine/access-engine and secrets-engine rather
than read directly.
Finding on the invited challenge to §5: do not weaken the binding rule,
but §4 catalogs kings-guard as owning containment while no engine exposes
a containment surface — the charter is currently undischargeable. Two
rulings requested of gate-house. Three engine gaps declared in INTENT.md.
Residual handed off as KG-IN-0002 (vocabulary sweep of the architecture
spec).
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
