Security Layer Model v0.2 — accepted

All three repositories whose boundaries moved assented, each with a decision
record (flex-auth FLEX-DEC-2026-001, kings-guard KG-DEC-2026-001, ops-warden
ADR-0010), and each returned a finding. v0.2 carries the results and is
accepted; v0.1 is marked superseded and retained because the twelve estate
INTENT review notes cite it.

- §5 restructured into three sanctioned shapes: read-only diagnostics, conduit
  (ops-warden's question, ruled), and declared engine gap (ops-warden's
  amendment, accepted). v0.1 offered only the first, which is narrower than the
  estate as it stands — a rule with no lane for a real sanctioned case gets
  satisfied by relabelling rather than by closing the gap.
- §6.2 added: doctrine must reach the decision as an input claim or a versioned
  policy rule. This is §6.1 applied to gate-house on the same terms it applies
  to engines, drawn back by flex-auth.
- §9 added: the catalog may not assign a capability the rules forbid
  discharging. Containment marked pending an engine surface; degraded-mode
  fallback ruled into access-engine rather than Staff.
- §11: conformance now has three states, distinguishing a tracked gap from an
  undeclared violation.
- §12 made normative, stating that an unsatisfiability finding is a success of
  the conformance loop.
- §13 added: open gaps register, including the unowned approval storage and
  lifecycle capability — recorded, deliberately not assigned.

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

README.md

@@ -12,7 +12,7 @@ The dynamic, self-optimizing security platform is the long-term direction in
 ## Orientation
 
 - [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant
-- [Security layer model](canon/standards/security-layer-model_v0.1.md) — how the
+- [Security layer model](canon/standards/security-layer-model_v0.2.md) — how the
   security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each
   layer may own
 - [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md)

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

@@ -3,7 +3,7 @@ id: netkingdom-security-layer-model-v0.1
 type: standard
 title: "NetKingdom Security Layer Model v0.1"
 domain: netkingdom
-status: proposed
+status: superseded
 version: "0.1"
 owner: gate-house
 publication_owner: net-kingdom
@@ -13,6 +13,7 @@ last_reviewed: "2026-08-28"
 review_interval: 3m
 source_revision: "gate-house@7f13f72"
 standard_token: security-layer-model_v0.1
+superseded_by: canon/standards/security-layer-model_v0.2.md
 related:
   - canon/standards/security-zones_v0.1.md
   - canon/standards/tenancy-posture_v0.1.md
@@ -25,6 +26,13 @@ related:
 
 # NetKingdom Security Layer Model v0.1
 
+> **Superseded 2026-08-28 by [v0.2](security-layer-model_v0.2.md).** All three
+> repositories whose boundaries moved assented to this version and each returned
+> a finding; v0.2 carries the results. Retained because the twelve estate
+> `INTENT.md` review notes cite this file. Read v0.2 for the current rules —
+> §5 (sanctioned shapes), §6.2 (doctrine as input), and §9 (capability
+> assignment) changed materially.
+
 ## 1. Purpose
 
 This standard states how NetKingdom's IT-security estate is layered, and what

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

@@ -0,0 +1,396 @@
+---
+id: netkingdom-security-layer-model-v0.2
+type: standard
+title: "NetKingdom Security Layer Model v0.2"
+domain: netkingdom
+status: accepted
+version: "0.2"
+supersedes: canon/standards/security-layer-model_v0.1.md
+owner: gate-house
+publication_owner: net-kingdom
+created: "2026-08-28"
+updated: "2026-08-28"
+last_reviewed: "2026-08-28"
+review_interval: 3m
+source_revision: "gate-house@4f618b4"
+standard_token: security-layer-model_v0.2
+assented_by:
+  - "flex-auth FLEX-DEC-2026-001"
+  - "kings-guard KG-DEC-2026-001"
+  - "ops-warden ADR-0010"
+related:
+  - canon/standards/security-zones_v0.1.md
+  - canon/standards/tenancy-posture_v0.1.md
+  - canon/standards/credential-management_v0.2.md
+  - gate-house/decisions/decisions.md
+  - gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md
+---
+
+# NetKingdom Security Layer Model v0.2
+
+## 1. Purpose
+
+This standard states how NetKingdom's IT-security estate is layered, and what
+each layer may and may not do. It answers one question:
+
+> **Given a repository, which layer is it in, and what does that permit it to
+> own?**
+
+The layers are distinguished by **determinism** and by **the kind of artifact
+the layer produces**, not by technical tier, deployment topology, or team.
+
+It is not an org chart, not a network model, not a deployment topology, and not
+a dependency graph. It does not assign work, and it does not replace any
+repository's boundary contract; it constrains what such a contract may claim.
+
+**What changed in v0.2.** v0.1 was assented to by all three repositories whose
+boundaries moved, and each returned a finding. v0.1 had one lane for a Staff
+repository that legitimately touches Tooling — read-only diagnostics — which is
+narrower than the estate as it actually stands, and a rule with no lane for a
+real sanctioned case is satisfied by relabelling rather than by closing the gap.
+v0.1 also catalogued a capability (§4, containment) that §5 forbade discharging,
+and applied its reconstructability test to engines but not to the doctrine
+gate-house feeds them. §15 records the full change list.
+
+## 2. Authority and conformance
+
+| Fact or rule | Authority |
+| --- | --- |
+| The layers, their definitions, and the rules between them | This standard, owned by gate-house |
+| Which layer a given repository is in | This standard, §4 catalog |
+| What a repository owns within its layer | That repository's `INTENT.md` and boundary contract |
+| Whether a specific request is permitted | `access-engine` — never this standard |
+| Whether a Tooling contact is sanctioned | The declaring repository, under the shapes in §5, reviewable by gate-house |
+| Security doctrine and invariants | gate-house |
+| Publication | net-kingdom canon |
+
+A repository conforms when its `INTENT.md` declares its layer, its claims fall
+within that layer's permissions (§3), and its Tooling contacts take one of the
+sanctioned shapes in §5 or are declared as gaps under §5.3.
+
+## 3. The layers
+
+| Layer | Character | Produces | Deterministic |
+| --- | --- | --- | --- |
+| **Taxonomy** | cross-cutting language | terms, semantic contracts, standards | n/a — describes |
+| **Tooling** | infrastructure and state | data structures, persistence | yes |
+| **Engines** | interfaces for a modeled concept | APIs, contracts | yes |
+| **Staff** | management, operations, change, controlling | specifications, decisions, workplans, tasks | **no** |
+
+### 3.1 Taxonomy
+
+Cross-cutting language. Taxonomy repositories define terms and semantic
+contracts so the other layers interoperate without integration by
+interpretation. They own no runtime position and no state any layer depends on.
+
+`info-tech-canon` holds ecosystem-wide semantic contracts. NetKingdom-specific
+security architecture — including this standard — is net-kingdom canon's.
+
+### 3.2 Tooling
+
+Deterministic infrastructure: data structures, persistence, and the consistent,
+performant, scalable keeping of state. Much of it is third-party.
+
+### 3.3 Engines
+
+Deterministic APIs for a modeled concept — a user, a tenant, a zone, a secret,
+an access rule. An engine's defining property is that **the same authoritative
+input state yields the same result**. Engines are where the estate's
+deterministic guarantees live, and therefore where every enforcement boundary
+MUST sit.
+
+A repository whose core function is inference or judgment fails this test by
+construction and is Staff, however much of its work happens at runtime.
+
+### 3.4 Staff
+
+Interactive and non-deterministic. Staff is the management layer: operations,
+change, innovation, and controlling. It works through agentic capability —
+assistants and autonomous agents — and its artifacts are specifications,
+decisions, workplans, and tasks.
+
+Staff repositories MUST NOT hold state that another layer depends on at
+runtime, and MUST NOT render or cache any decision an Engine is responsible for.
+
+Acting at runtime does not make a repository an Engine. Being agentic makes it
+Staff, and §5 governs how it acts.
+
+## 4. Layer catalog
+
+| Repository | Layer | Owns |
+| --- | --- | --- |
+| `info-tech-canon` | Taxonomy | ecosystem-wide semantic contracts and terminology |
+| `net-kingdom` | Taxonomy | NetKingdom standards of record; publication |
+| `key-cape` | Tooling | packaged identity tooling; IAM profile; authentication |
+| `OpenBao` | Tooling | secret storage, leases, PKI, dynamic secret engines |
+| `user-engine` | Engine | users, accounts, memberships |
+| `tenant-engine` | Engine | tenant-as-an-entity facts |
+| `zone-engine` | Engine | zone identity and membership — offline reference conformance per its 2026-08-23 disposition |
+| `secrets-engine` | Engine | credential abstraction, custody, lifecycle |
+| `access-engine` | Engine | **the policy decision** — the only decision point (§6) |
+| `gate-house` | Staff | security doctrine, authority context, conformance review, curriculum |
+| `ops-mason` | Staff | building and tearing down access routes and perimeters |
+| `ops-warden` | Staff | operational access lanes, stewardship, runbooks; SSH certificate issuance |
+| `kings-guard` | Staff | adaptive defence, observation; **containment — pending (§9.2)** |
+| `whitehat-security` | Staff | offensive validation |
+
+`access-engine` is the ruled name for the repository currently called
+`flex-auth`; both denote the same authority until the governed rename completes.
+Execution conditions for that rename are recorded in its migration decision, not
+here.
+
+## 5. The binding rule
+
+> **Staff never touches Tooling directly. It acts only through Engine APIs.**
+
+A Staff repository MUST NOT hold a direct client for a Tooling-layer system —
+no direct database connection, no direct OpenBao client, no direct cluster
+mutation — outside the shapes below. This is the architectural form of *no
+privilege from cognition*, and it is deliberately mechanically checkable.
+
+Three shapes are sanctioned. Everything else is a violation.
+
+### 5.1 Read-only diagnostic observation
+
+A Staff repository MAY read Tooling state for diagnostics where the owning
+engine exposes no equivalent. It MUST be declared in the repository's
+`INTENT.md`. It grants no write, and it is an engine gap to close, not a
+standing arrangement.
+
+### 5.2 Conduit
+
+A Staff repository MAY run the **owner's** tool under the **caller's** identity,
+supplying no authority of its own. The test is the supplied-authority property:
+the conduit MUST NOT present its own credential, MUST NOT widen what the caller
+could already do, and MUST be reconstructable as the caller's action in audit.
+
+A conduit that presents its own token is not a conduit; it is §5.3 or a
+violation. This shape MUST be declared, and the no-authority property SHOULD be
+covered by a test.
+
+### 5.3 Declared engine gap
+
+Where a Staff repository must contact Tooling directly and no engine exposes the
+capability, it MUST declare the contact rather than take an exemption. A
+declared gap carries, machine-readably:
+
+| Field | Meaning |
+| --- | --- |
+| `capability` | what the contact does |
+| `intended_owner` | the engine that should own it |
+| `blocked_on` | why it cannot move today |
+| `review` | a date, not "when convenient" |
+
+A declared gap is **tracked non-conformance**, not conformance. It does not
+expire on its own and it is not a licence to add more. It exists because a rule
+offering no lane for a real sanctioned case gets satisfied by relabelling rather
+than by closing the gap — and a tracked gap is visible, whereas a relabelled one
+is not.
+
+Prior art: `ops-warden` runs equivalent machinery for delegated lanes (27
+catalog entries carrying `delegation:`, queryable via `warden route gaps`), and
+has offered it as reusable.
+
+## 6. One decision point
+
+`access-engine` is the only policy decision point in NetKingdom. No other
+repository, in any layer, may render or cache authorization decisions.
+
+First ruled in `zone-engine/INTENT.md` §5 — *"flex-auth is the policy decision
+point. It stays the only one."* The failure mode, from the same source: *"It
+becomes a second decision point… it would arrive as a small convenience."*
+
+### 6.1 Compiled data that determines an outcome is still deciding
+
+A registry, cache, or schema that resolves a result before the engine runs has
+decided early. Provenance MUST remain reconstructable from the engine's decision
+record.
+
+### 6.2 Doctrine reaches the decision as an input, or it is not applied
+
+This rule binds gate-house on the same terms. **An authority ceiling, mandate
+constraint, or operating-mode restriction that determines an outcome MUST reach
+the decision either as an input claim on the request or as a rule in the
+versioned policy package**, so that its application is reconstructable from the
+decision record.
+
+Doctrine that influences outcomes by any other route is a second decision point
+wearing an author's hat. This is not a limit on gate-house's authorship; it is
+what keeps that authorship auditable at decision time.
+
+### 6.3 No Staff repository may host a decision point
+
+A deterministic authority boundary inside a non-deterministic layer contradicts
+the invariant the estate is built on. gate-house was re-cut on this ground.
+
+## 7. Relationship to the Active Secrets Management Canon
+
+```text
+Staff       interactive, non-deterministic   ≈  Cognitive Plane
+Engines     deterministic APIs               ≈  Authority Plane
+Tooling     deterministic state              ≈  Execution Plane
+Taxonomy    cross-cutting language
+```
+
+*Cognition proposes. Authority disposes. Infrastructure executes.* is therefore
+NetKingdom's layering rule, not only its security maxim. §5 and §6 are that
+principle applied to repositories rather than to requests.
+
+## 8. Vocabulary demarcations
+
+| Term | Belongs to | Not |
+| --- | --- | --- |
+| **access lane** | ops-warden, ops-mason (Staff) — how a worker reaches a host | the decision whether they may |
+| **access rule** | access-engine (Engine) — whether an actor may act | the route by which they arrive |
+| **control plane** | Engine layer | a Staff repository's self-description |
+| **doctrine** | gate-house | a lane owner's runbook |
+| **runbook** | the Staff repository stewarding the lane | a substitute for doctrine |
+| **posture** | kings-guard publishes; gate-house defines its authority meaning; access-engine renders it | a privilege source |
+
+Posture carries an asymmetry that MUST hold: adaptive systems may reduce
+authority, require step-up, or request containment. They MUST NOT
+probabilistically manufacture additional authority.
+
+## 9. Capability assignment
+
+### 9.1 The catalog may not assign what the rules forbid discharging
+
+A Staff repository MUST NOT be catalogued in §4 as owning a capability that
+requires a Tooling contact no engine exposes. Where the capability is intended
+but the engine surface does not yet exist, the catalog entry MUST be marked
+**pending** and the gap declared under §5.3.
+
+v0.1 violated this: it catalogued kings-guard as owning containment while §5
+forbade the only route to discharging it, making the capability zero rather than
+degraded. Raised by kings-guard, KG-DEC-2026-001.
+
+### 9.2 Containment is pending an engine surface
+
+No engine exposes a containment surface today — nothing to reduce authority,
+require step-up, or isolate a workload as a deterministic API. kings-guard's
+containment claim is marked pending in §4 until one exists.
+
+### 9.3 Degraded-mode fallback belongs inside the engine
+
+Where a capability must survive partial failure, the fallback belongs to the
+engine, not to Staff. The deterministic *fail to reduced authority* default is
+`access-engine`'s, applied when it cannot reach its own inputs.
+
+This keeps the decision at the decision point and keeps the fallback
+deterministic — which a Staff-layer fallback could never be. It is also why
+engine-unavailable is not grounds for a Staff break-glass path: an incident is
+when an attacker most wants the shortcut, and a containment path that bypasses
+the decision point becomes an authority path the moment it is subverted.
+
+## 10. Changing layer
+
+A repository's layer is not permanent. `zone-engine` changed layer in practice
+when its runtime hypothesis was falsified.
+
+A layer change MUST be recorded as a decision, MUST update the repository's
+`INTENT.md`, and MUST obtain assent from the repositories whose boundaries move.
+A repository MUST NOT acquire a new layer's permissions by gradual practice.
+
+## 11. Conformance
+
+Conformance has three states, and the distinction is the point:
+
+| State | Meaning |
+| --- | --- |
+| **Conforming** | no Tooling contact, or only §5.1/§5.2 shapes, declared |
+| **Declared gap** | a §5.3 contact with owner, blocker, and review date — tracked non-conformance |
+| **Undeclared violation** | anything else — a finding |
+
+Mechanically checkable:
+
+- every repository in §4 declares its layer in `INTENT.md`;
+- every direct Tooling client in a Staff repository maps to a declared §5.1,
+  §5.2, or §5.3 entry;
+- no repository other than `access-engine` exposes an authorization decision
+  surface;
+- no §4 capability is catalogued without an engine surface or a pending mark.
+
+Requires review: whether claims stay inside layer permissions; whether compiled
+or cached data has become an early decision (§6.1); whether doctrine is reaching
+decisions as declared inputs (§6.2); whether the §8 vocabulary is used correctly.
+
+## 12. The conformance loop
+
+Doctrine no engine implements is fiction. The loop is normative, not
+aspirational:
+
+```text
+gate-house asserts an invariant
+      → the engines implement it, or declare a gap
+      → whitehat-security tries to break it
+      → kings-guard observes it in operation
+      → findings return to gate-house as doctrine change
+```
+
+A finding that a rule is unsatisfiable is a **success** of this loop, not a
+failure of the reporting repository. v0.2 exists because three repositories used
+it on first contact.
+
+## 13. Open gaps
+
+Declared under §5.3 or raised as unowned capability, as of 2026-08-28:
+
+| Gap | Declared by | Intended owner |
+| --- | --- | --- |
+| SSH-CA signing write (`VaultCA`, `bao kv put`) | ops-warden | secrets-engine |
+| Authentication / assurance evidence | kings-guard | user-engine, access-engine |
+| Secret-use evidence | kings-guard | secrets-engine |
+| Containment surface | kings-guard | access-engine + runtime engines |
+| Registry-snapshot digest in decision provenance | flex-auth | flex-auth (self-declared) |
+| **Approval storage and lifecycle** — durable object, authenticated entries, atomic supersession | flex-auth | **unowned — see below** |
+
+The approval gap is the one open architectural hole. It is not gate-house's
+(§3.4 forbids Staff holding state another layer depends on at runtime) and not
+access-engine's (it does not own the organizational approval lifecycle). It
+blocks `FLEX-WP-0017` T03 and T05. Assigning it requires a decision and the
+assent of the receiving repository; this standard records the gap and does not
+assign it.
+
+## 14. Adoption
+
+Status is **accepted**. All three repositories whose boundaries moved have
+assented in writing, each with a decision record:
+
+| Repository | Record | Outcome |
+| --- | --- | --- |
+| flex-auth | `FLEX-DEC-2026-001` | assent to all three items; one self-declared non-conformance; two rename conditions |
+| kings-guard | `KG-DEC-2026-001` | assent; declined the offered §5 relaxation; raised §9.1 |
+| ops-warden | `ADR-0010` | assent to all three; veto not exercised; offered the §5.3 amendment |
+
+Adoption for a repository means its `INTENT.md` declares its layer, its
+ownership claims fall inside that layer, its Tooling contacts are declared under
+§5, and any shared boundary has been assented to by the other side.
+
+## 15. Change log
+
+v0.1 → v0.2:
+
+1. **§5 restructured** into three sanctioned shapes. Added §5.2 conduit
+   (ops-warden's question, ruled) and §5.3 declared engine gap (ops-warden's
+   amendment, accepted).
+2. **§6.2 added** — doctrine must reach the decision as an input claim or a
+   versioned policy rule (flex-auth's boundary drawn back, accepted).
+3. **§9 added** — the catalog may not assign a capability the rules forbid
+   discharging; containment marked pending; degraded-mode fallback ruled into
+   the engine (kings-guard's finding).
+4. **§11 restructured** — conformance now has three states, distinguishing a
+   tracked gap from an undeclared violation.
+5. **§12 made normative**, with the explicit statement that an
+   unsatisfiability finding is a success of the loop.
+6. **§13 added** — open gaps register, including the unowned approval storage
+   and lifecycle capability.
+7. §4 catalog gained the pending mark and ops-warden's SSH certificate lane.
+
+## 16. Open questions
+
+- Who owns approval storage and lifecycle (§13). The only structural hole.
+- Whether Tooling warrants subdivision between third-party and homegrown.
+- How a future `role-engine` divides responsibility with `access-engine`.
+- Whether declared gaps need an estate-wide register rather than per-repository
+  declarations; ops-warden's `warden route gaps` is candidate machinery.
+- Whether non-security repositories adopt the same model.