Security Layer Model v0.5 — four reviews, nine changes

All four reviewing repositories returned findings on v0.4 and one contested a
rule. Every change below came from a reviewer, not from gate-house.

- §9.1 split into `pending` (no route, capability zero) and `declared-gap`
  (route exists under §5.3, capability works). v0.4's single mark would have
  forced a false "pending" onto ops-warden's production SSH issuance —
  the fix was worse than the defect, and the defect was in this section.
- §9.3 rewritten. flex-auth contested it and was right: it collapsed "engine
  reachable but degraded" with "engine unreachable", and the second has no
  evaluator in the path to express anything. Input degradation is the engine's;
  unreachability is the consumer's, bounded by a declared auditable total
  stance — which ops-warden ADR-0009 already satisfies. v0.4 had ruled against
  shipped behaviour in a repository that assented to it.
- §5 scoped: "Tooling-layer system" means a §4 Tooling row. Without this every
  Staff repository was in undeclared violation for writing progress events.
- §9.4 requires the outbox to be local — no synchronous audit-core dependency
  inside the state-change transaction, so an audit outage cannot block a
  revocation.
- §9.5 forbids compiling maturity levels into registry content while decision
  provenance carries no registry-snapshot digest.
- §9.6 gained load-bearing versus attributive evidence, the mirror rule that
  absence is not evidence of non-occurrence, and kings-guard's finding that
  suppression biases posture optimistic and silently.
- §11 gained a fourth state: blocked-clean, which MUST NOT rank below
  conforming. A repository that declined a break-glass path and left a
  capability at zero complied at cost; one that quietly opened a client and
  declared nothing did not.
- §11 gained a machine-readable declaration form; ops-warden's layer.yaml is
  the reference implementation.
- §13 gained state and owner-status columns; access-engine's decline of
  authentication evidence is recorded.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9

canon/standards/security-layer-model_v0.4.md

@@ -3,7 +3,7 @@ id: netkingdom-security-layer-model-v0.4
 type: standard
 title: "NetKingdom Security Layer Model v0.4"
 domain: netkingdom
-status: proposed
+status: superseded
 version: "0.4"
 supersedes: canon/standards/security-layer-model_v0.3.md
 owner: gate-house
@@ -14,6 +14,7 @@ last_reviewed: "2026-08-28"
 review_interval: 3m
 source_revision: "gate-house@516ed4e"
 standard_token: security-layer-model_v0.4
+superseded_by: canon/standards/security-layer-model_v0.5.md
 assented_by:
   - "flex-auth FLEX-DEC-2026-001"
   - "kings-guard KG-DEC-2026-001"
@@ -29,6 +30,11 @@ related:
 
 # NetKingdom Security Layer Model v0.4
 
+> **Superseded 2026-08-29 by [v0.5](security-layer-model_v0.5.md).** All four
+> reviewing repositories returned findings; `flex-auth` contested §9.3 and was
+> right. v0.5 splits §9.1 into two marks, rewrites §9.3, scopes §5, requires a
+> local outbox in §9.4, and gives §11 a fourth conformance state.
+
 ## 1. Purpose
 
 This standard states how NetKingdom's IT-security estate is layered, and what