repo.work.create_intake NET-IN-0001

correlation_id: 980dc589-1d44-4097-b2f6-419e5bd21fd1
reason: Request own-voice layer declaration under §11
source: repo-manager

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

INTENT.md

@@ -1,5 +1,20 @@
 # INTENT
 
+> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed
+> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines →
+> Staff**, layered by determinism and by the kind of artifact each layer produces.
+> Findings and the argument behind them:
+> `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
+> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
+> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001.
+>
+> The layer rule that binds every repository: **Staff never touches tooling
+> directly. It acts only through engine APIs.**
+>
+> **This repository is Taxonomy — the estate's canon of record.** The layer model belongs here, in `canon/standards/`, as NetKingdom-flavored security architecture rather than general semantic contract. This INTENT should name the four layers as the structure of the estate and reference the standard once written. The canon currently holds no authority or Active Secrets Management standard, and does not mention gate-house at all.
+>
+> *This note records what should change. The body below is not yet adapted.*
+
 > This file captures **why this repository exists**,
 > the **direction it is moving toward**, and
 > the **kind of system it is meant to become**.

README.md

@@ -12,6 +12,9 @@ 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.4.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)
   — deterministic, plan-only capability and trust composition
 - [Posture feedback](canon/standards/posture-feedback_v0.1.md) — deterministic,

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

@@ -0,0 +1,283 @@
+---
+id: netkingdom-security-layer-model-v0.1
+type: standard
+title: "NetKingdom Security Layer Model v0.1"
+domain: netkingdom
+status: superseded
+version: "0.1"
+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@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
+  - canon/standards/credential-management_v0.2.md
+  - canon/standards/user-engine-boundary-contract_v0.1.md
+  - canon/standards/tenant-engine-boundary-contract_v0.1.md
+  - gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md
+  - gate-house/INTENT.md
+---
+
+# 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
+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 model exists because the estate acquired overlapping claims to the same
+responsibility — most visibly, two repositories describing themselves as the
+authorization control plane — and the overlap was invisible in each
+repository's own documents. A layer assignment makes the claim explicit and
+checkable.
+
+The layers are distinguished by **determinism** and by **the kind of artifact
+the layer produces**, not by technical tier, deployment topology, or team.
+
+This standard 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.
+
+## 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 |
+| 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 it satisfies the binding rule (§5).
+
+## 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 can 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. The
+two MUST NOT be read as competing: the first names things for the whole
+ecosystem, the second rules on NetKingdom security.
+
+### 3.2 Tooling
+
+Deterministic infrastructure: data structures, persistence, and the consistent,
+performant, scalable keeping of state. Much of it is third-party; some is
+homegrown; all of it is infrastructure.
+
+Tooling MUST be reachable from Staff only through an Engine (§5).
+
+### 3.3 Engines
+
+Deterministic APIs for a modeled concept — a user, a tenant, a zone, a secret,
+an access rule. An engine provides the functionality that concept needs and
+exposes it as a contract. New concepts become new engines as they become
+relevant.
+
+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.
+
+### 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 that an Engine is
+responsible for.
+
+Staff includes repositories that act at runtime, such as adaptive defence and
+offensive validation. Acting at runtime does not make a repository an Engine;
+being agentic makes it Staff, and §5 governs how it acts.
+
+## 4. Layer catalog
+
+Current assignment for the security estate. Adding a repository to this catalog
+is a change to this standard.
+
+| 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 (authelia, lldap, privacy-idea); 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 — retained as 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 and defence 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 |
+| `kings-guard` | Staff | adaptive defence, observation, containment |
+| `whitehat-security` | Staff | offensive validation |
+
+`access-engine` is the ruled name for the repository currently called
+`flex-auth`. Until the governed rename completes, `flex-auth` is the same
+repository under its former name; references to either denote the same
+authority.
+
+## 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 — and MUST route the equivalent need through the owning engine.
+
+This is the architectural form of *no privilege from cognition*. It is why
+`kings-guard` may contain a threat only by calling an engine, and why an
+autonomous coding agent gets no shortcut around one.
+
+The rule is deliberately mechanically checkable: a Staff repository holding
+such a client is in violation, and the violation is greppable. A Staff
+repository needing a capability no engine exposes MUST raise that as an engine
+gap, not solve it locally.
+
+Read-only observation of Tooling for diagnostics MAY be permitted where the
+owning engine exposes no equivalent, but it MUST be declared in the Staff
+repository's `INTENT.md` and treated as an engine gap to close, not a standing
+arrangement.
+
+## 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.
+
+This was first ruled in `zone-engine/INTENT.md` §5 — *"flex-auth is the policy
+decision point. It stays the only one."* — drawn by flex-auth on review of a
+zone-engine draft that had it wrong. This standard generalizes that ruling from
+one repository to the whole estate.
+
+The failure mode is stated in the same source, and is adopted here:
+
+> *"It becomes a second decision point. The failure would not announce itself;
+> it would arrive as a small convenience."*
+
+Two consequences follow:
+
+- **Compiled data that determines an outcome is still deciding.** A registry, a
+  cache, or a schema that resolves a result before the engine runs has decided
+  early. Provenance must remain reconstructable from the engine's decision.
+- **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 precisely this ground.
+
+## 7. Relationship to the Active Secrets Management Canon
+
+Read by determinism, the layers reproduce the Canon's three planes:
+
+```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. The estate's structure
+is an instance of the principle its security canon teaches, and §5 and §6 are
+that principle applied to repositories rather than to requests.
+
+## 8. Vocabulary demarcations
+
+Words the estate has used for more than one thing. These bindings are
+normative.
+
+| Term | Belongs to | Not |
+| --- | --- | --- |
+| **access lane** | ops-warden, ops-mason (Staff) — how a worker reaches a host | the decision about 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 that stewards 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. Changing layer
+
+A repository's layer is not permanent. `zone-engine` changed layer in practice
+when its runtime hypothesis was falsified and it was retained as offline
+reference conformance rather than an engine.
+
+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
+as a result. A repository MUST NOT acquire a new layer's permissions by
+gradual practice.
+
+## 10. Conformance
+
+Mechanically checkable:
+
+- every repository in §4 declares its layer in `INTENT.md`;
+- no Staff repository holds a direct Tooling client (§5);
+- no repository other than `access-engine` exposes an authorization decision
+  surface (§6).
+
+Requires review:
+
+- whether a repository's claims stay inside its layer's permissions;
+- whether compiled or cached data has become an early decision (§6);
+- whether the demarcated vocabulary in §8 is used correctly.
+
+## 11. Adoption
+
+Status is **proposed**. The estate's `INTENT.md` files carry a review note as
+of 2026-08-28 recording each repository's layer and the adaptation this
+standard implies; the bodies are not yet adapted.
+
+Adoption for a repository means: its `INTENT.md` declares its layer, its
+ownership claims fall inside that layer, and any boundary it shares has been
+assented to by the other side — as flex-auth and zone-engine did on review.
+
+Two adaptations carry the most weight and are not yet assented:
+
+1. `flex-auth` reframed as an Engine, renamed `access-engine`, with policy
+   authoring separated from policy evaluation.
+2. `kings-guard` and `ops-warden` releasing vocabulary — "control plane" and
+   the security curriculum respectively — to the layer that owns it.
+
+## 12. Open questions
+
+- Whether Tooling warrants subdivision between third-party and homegrown
+  components; v0.1 deliberately does not.
+- How a future `role-engine` divides responsibility with `access-engine`,
+  given roles are inputs to access rules.
+- Whether non-security repositories in the wider estate adopt the same model,
+  or whether it stays scoped to the security estate as v0.1 assumes.

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

@@ -0,0 +1,402 @@
+---
+id: netkingdom-security-layer-model-v0.2
+type: standard
+title: "NetKingdom Security Layer Model v0.2"
+domain: netkingdom
+status: superseded
+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
+superseded_by: canon/standards/security-layer-model_v0.3.md
+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
+
+> **Superseded 2026-08-28 by [v0.3](security-layer-model_v0.3.md)**, which assigns
+> the approval and maturity concepts §13 recorded as unowned. The assent record in
+> §14 remains the basis on which the model was accepted; v0.3 changes §4, §9, and
+> §13 only.
+
+## 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.

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

@@ -0,0 +1,471 @@
+---
+id: netkingdom-security-layer-model-v0.3
+type: standard
+title: "NetKingdom Security Layer Model v0.3"
+domain: netkingdom
+status: superseded
+version: "0.3"
+supersedes: canon/standards/security-layer-model_v0.2.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@516ed4e"
+standard_token: security-layer-model_v0.3
+superseded_by: canon/standards/security-layer-model_v0.4.md
+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.3
+
+> **Superseded 2026-08-28 by [v0.4](security-layer-model_v0.4.md).** `audit-core`
+> assented to §9.4 and corrected its rationale twice: this version rested the
+> evidence argument on an aspirational INTENT principle rather than the shipped
+> integrity bound, and did not state that no append-only archive can prove
+> omission at source. v0.4 also catalogues `audit-core`, which this version
+> named as an owner without listing.
+
+## 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.3.** Two engines were seeded to own concepts v0.2 recorded
+as unowned: `approval-engine` takes the approval object that §13 left homeless,
+and `maturity-engine` takes graded progression — closing a §9.1 defect in
+gate-house's own catalog claim, which asserted conformance review with no engine
+to act through. §15 records the change list. v0.3 is **proposed**: the two new
+engines are seeded by owner direction and have no other side to assent yet, and
+the evidence half of the approval split needs `audit-core`'s assent.
+
+**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) |
+| `approval-engine` | Engine | the approval object — durable, authenticated, consumable, atomically supersedable (§9.4) |
+| `maturity-engine` | Engine | graded progression against declared criteria and evidence; the gap register; capability readiness (§9.5) |
+| `gate-house` | Staff | security doctrine, authority context, curriculum; **conformance review — through `maturity-engine` (§9.5)** |
+| `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.
+
+### 9.4 Approvals are an engine concept, not a Staff or audit concern
+
+The approval object — durable, authenticated entries, distinct-approver
+counting, atomic supersession, single consumption, revocation without holder
+cooperation — is owned by `approval-engine`.
+
+It is not Staff's: §3.4 forbids Staff holding state another layer depends on at
+runtime. It is not the decision point's: an evaluator that owns the object it
+evaluates is self-dealing. It is not the audit fabric's: an approval needs
+mutable, in-path, current-state semantics, and an append-only archive is built
+for the opposite property.
+
+`access-engine` consumes approvals as **input claims** under §6.2 and never
+mutates them. Every issuance, use, supersession, and revocation is emitted to
+`audit-core` as tamper-evident evidence: the operative state and the evidence
+record are different artifacts with different owners.
+
+### 9.5 Graded progression is an engine concept
+
+Maturity — how far a subject has progressed against declared criteria and
+submitted evidence — is owned by `maturity-engine`. Given the same criteria and
+the same evidence it MUST return the same level; that determinism is what makes
+it an Engine rather than an opinion.
+
+The division with Staff: **gate-house judges and proposes; maturity-engine
+computes and remembers.** Interpretation is inference and stays Staff. A
+criterion that cannot be evaluated by rule is not yet a criterion.
+
+This closes a defect in v0.2's own catalog: `gate-house` was assigned
+conformance review with no engine to act through, which is exactly the §9.1
+problem raised against the containment claim. Staff acts only through Engine
+APIs, including gate-house.
+
+**A maturity level MUST NOT gate a decision directly.** Under §6.1, compiled
+data that determines an outcome is still deciding. If a level determines whether
+an action is permitted, it MUST reach `access-engine` as an input claim or a
+versioned policy rule under §6.2, never by a consumer branching on a fetched
+level.
+
+Approvals and maturity are deliberate opposites — a closed binary state machine
+against an open graded ladder — and neither engine may drift toward the other.
+
+## 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 | **`approval-engine`** — assigned in v0.3 (§9.4) |
+| Approval evidence — tamper-evident record of issuance, use, supersession, revocation | gate-house | `audit-core` — proposed, assent pending |
+| Conformance review has no engine surface | gate-house (self) | **`maturity-engine`** — assigned in v0.3 (§9.5) |
+
+The approval gap is resolved in v0.3 by seeding `approval-engine` (§9.4), which
+unblocks `FLEX-WP-0017` T03 and T05 once implemented. Its evidence half is
+proposed to `audit-core` and awaits that repository's assent.
+
+Gaps are recorded here but tracked in `maturity-engine` (§9.5) once it exists;
+this table is the interim register and should not outlive 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.
+
+v0.2 → v0.3:
+
+1. **§9.4 added** — approvals assigned to `approval-engine`, with the operative
+   state and the evidence record separated between it and `audit-core`.
+2. **§9.5 added** — graded progression assigned to `maturity-engine`, closing
+   the §9.1 defect in gate-house's own conformance-review claim, and carrying
+   the guardrail that a level may never gate a decision directly.
+3. §4 catalog gained both engines; gate-house's conformance-review claim now
+   names the engine it acts through.
+4. §13 register updated: the approval hole is assigned, two new entries added.
+
+## 16. Open questions
+
+- Whether `audit-core` accepts the approval evidence half (§9.4, §13).
+- Whether the gap register migrates from this standard into `maturity-engine`
+  once that engine exists, leaving the standard to state the rules only.
+- 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.

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

@@ -0,0 +1,583 @@
+---
+id: netkingdom-security-layer-model-v0.4
+type: standard
+title: "NetKingdom Security Layer Model v0.4"
+domain: netkingdom
+status: proposed
+version: "0.4"
+supersedes: canon/standards/security-layer-model_v0.3.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@516ed4e"
+standard_token: security-layer-model_v0.4
+assented_by:
+  - "flex-auth FLEX-DEC-2026-001"
+  - "kings-guard KG-DEC-2026-001"
+  - "ops-warden ADR-0010"
+  - "audit-core AUDIT-IN-0001 (evidence half, assent with conditions)"
+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.4
+
+## 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.4.** `audit-core` assented to the approval evidence half
+and corrected the rationale twice. v0.3 rested §9.4 on that repository's INTENT
+principle 6, which is an aspiration; the shipped bound in its `docs/integrity.md`
+is weaker and conditional. More consequentially, no append-only archive can prove
+**omission at source** — a suppressed revocation leaves the chain intact — which
+is now stated as an estate-wide doctrine constraint (§9.6) rather than left
+implicit. `audit-core` was also referenced as an owner in v0.3 without appearing
+in the §4 catalog at all; it is catalogued here, as an Engine, on its own
+declaration. §15 records the change list.
+
+**What changed in v0.3.** Two engines were seeded to own concepts v0.2 recorded
+as unowned: `approval-engine` takes the approval object that §13 left homeless,
+and `maturity-engine` takes graded progression — closing a §9.1 defect in
+gate-house's own catalog claim, which asserted conformance review with no engine
+to act through. §15 records the change list. v0.3 is **proposed**: the two new
+engines are seeded by owner direction and have no other side to assent yet, and
+the evidence half of the approval split needs `audit-core`'s assent.
+
+**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 |
+| `audit-core` | Engine | audit event custody, retention, integrity verification, export — explicitly not a decision point (§9.6) |
+| `access-engine` | Engine | **the policy decision** — the only decision point (§6) |
+| `approval-engine` | Engine | the approval object — durable, authenticated, consumable, atomically supersedable (§9.4) |
+| `maturity-engine` | Engine | graded progression against declared criteria and evidence; the gap register; capability readiness (§9.5) |
+| `gate-house` | Staff | security doctrine, authority context, curriculum; **conformance review — through `maturity-engine` (§9.5)** |
+| `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.
+
+### 9.4 Approvals are an engine concept, not a Staff or audit concern
+
+The approval object — durable, authenticated entries, distinct-approver
+counting, atomic supersession, single consumption, revocation without holder
+cooperation — is owned by `approval-engine`.
+
+It is not Staff's: §3.4 forbids Staff holding state another layer depends on at
+runtime. It is not the decision point's: an evaluator that owns the object it
+evaluates is self-dealing. It is not the audit fabric's: an approval needs
+mutable, in-path, current-state semantics, and an append-only archive is built
+for the opposite property.
+
+`access-engine` consumes approvals as **input claims** under §6.2 and never
+mutates them. Every issuance, use, supersession, and revocation is emitted to
+`audit-core`: the operative state and the evidence record are different
+artifacts with different owners.
+
+The evidence guarantee is bounded, and the bound is `audit-core`'s
+`docs/integrity.md`, not its INTENT principle 6. An in-database hash chain
+detects a rewritten payload only if the attacker does not also recompute the
+suffix — which a database owner can. Detection against that class requires the
+external chain-head attestation, and even with it the store is not WORM, object
+lock, or archival custody. `tamper_evidence` is therefore conditional on live
+preconditions, not a property of the store at rest, and approval events receive
+exactly the guarantee every other source receives.
+
+**Emission atomicity is `approval-engine`'s obligation.** An approval MUST NOT be
+issued, consumed, superseded, or revoked without the corresponding event being
+durably queued in the same transaction — transactional outbox or equivalent.
+`audit-core` reports what it received and does not imply it is everything that
+happened; without atomic emission the evidence half is silently incomplete and
+nothing detects the gap. This is a condition of `audit-core`'s assent
+(`AUDIT-IN-0001`) and belongs in `approval-engine`'s contract before the evidence
+half is treated as load-bearing.
+
+`audit-core` MUST NOT expose an approval-validity query. Records, yes; a verdict
+on whether an approval is still valid, never — a consumer branching on that
+answer would route an authorization decision through the audit fabric, which is
+what this section exists to prevent. Callers needing current state ask
+`approval-engine`.
+
+### 9.5 Graded progression is an engine concept
+
+Maturity — how far a subject has progressed against declared criteria and
+submitted evidence — is owned by `maturity-engine`. Given the same criteria and
+the same evidence it MUST return the same level; that determinism is what makes
+it an Engine rather than an opinion.
+
+The division with Staff: **gate-house judges and proposes; maturity-engine
+computes and remembers.** Interpretation is inference and stays Staff. A
+criterion that cannot be evaluated by rule is not yet a criterion.
+
+This closes a defect in v0.2's own catalog: `gate-house` was assigned
+conformance review with no engine to act through, which is exactly the §9.1
+problem raised against the containment claim. Staff acts only through Engine
+APIs, including gate-house.
+
+**A maturity level MUST NOT gate a decision directly.** Under §6.1, compiled
+data that determines an outcome is still deciding. If a level determines whether
+an action is permitted, it MUST reach `access-engine` as an input claim or a
+versioned policy rule under §6.2, never by a consumer branching on a fetched
+level.
+
+Approvals and maturity are deliberate opposites — a closed binary state machine
+against an open graded ladder — and neither engine may drift toward the other.
+
+### 9.6 Evidence proves alteration and truncation, not omission at source
+
+An append-only archive with a verified hash chain proves that records were not
+**altered or truncated after arrival**. It cannot prove that a record was never
+sent. Against a compromised or buggy source, a suppressed event leaves the chain
+perfectly intact and verification reports intact.
+
+This bound is estate-wide and MUST be respected wherever doctrine relies on
+audit. Statements of the form *"the audit record proves it happened"* are
+unsound; the sound form is *"the archive proves the records it holds were not
+altered or truncated after arrival"*.
+
+Two consequences:
+
+1. **Completeness is the source's obligation, not the archive's.** Any system
+   whose evidence is load-bearing MUST make emission atomic with the state
+   change it records (§9.4). An archive cannot retrofit completeness.
+2. **The most valuable event to suppress is the negative one.** A withheld
+   revocation, denial, or containment action is exactly what an adversary wants
+   missing, and it is the case least visible to chain verification. Controls
+   that depend on such events MUST NOT treat archive integrity as evidence of
+   their occurrence.
+
+Raised by `audit-core` while assenting to §9.4, against its own principle 6.
+
+## 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 |
+
+**Who must declare.** A repository the estate authors declares its layer in its
+own `INTENT.md`, in its own voice. For a component the estate catalogues but does
+not author — third-party or vendored, such as `OpenBao` — the §4 catalog row
+**is** the declaration, and no `INTENT.md` obligation attaches. A rule that
+assigns an obligation the holder cannot discharge is the §9.1 defect applied to
+conformance rather than capability.
+
+A layer stated *about* a repository by another repository is not a declaration.
+Review notes, catalog rows, and correspondence record an intent to adopt; only
+the repository's own file, in its own voice, conforms.
+
+Mechanically checkable:
+
+- every estate-authored repository in §4 declares its layer in its own
+  `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 | **`approval-engine`** — assigned in v0.3 (§9.4) |
+| Approval evidence — record of issuance, use, supersession, revocation | gate-house | `audit-core` — **assented with conditions** (`AUDIT-IN-0001`) |
+| Approval evidence custody stronger than the shipped bound — WORM, object lock, or transparency log | audit-core | unassigned — declared under §5.3, see below |
+| Emission atomicity for approval state changes | audit-core | `approval-engine` — condition of the above assent (§9.4) |
+| Conformance review has no engine surface | gate-house (self) | **`maturity-engine`** — assigned in v0.3 (§9.5) |
+
+The approval gap is resolved in v0.3 by seeding `approval-engine` (§9.4), which
+unblocks `FLEX-WP-0017` T03 and T05 once implemented. Its evidence half is
+proposed to `audit-core` and awaits that repository's assent.
+
+The approval evidence half is assented by `audit-core` with conditions, and one
+of those conditions opened a new gap: approvals plausibly warrant custody
+stronger than the shipped bound — WORM, object lock, or a transparency log —
+which `audit-core` correctly says is an engine gap to declare rather than a
+setting to enable. It is declared here, unassigned, because deciding whether
+approvals need archival custody distinct from every other source is doctrine
+work that has not been done. Until it is, approval evidence carries the same
+guarantee as any other source, and §9.6 bounds what may be claimed from it.
+
+Gaps are recorded here but tracked in `maturity-engine` (§9.5) once it exists;
+this table is the interim register and should not outlive 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 |
+| audit-core | `AUDIT-IN-0001` | assent to the evidence half with conditions; corrected the rationale twice; raised §9.6 |
+
+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.
+
+**Adoption status as of 2026-08-28: seven of fifteen** estate-authored §4
+repositories have declared in their own voice — `gate-house`, `flex-auth`,
+`kings-guard`, `ops-warden`, `audit-core`, `approval-engine`, `maturity-engine`.
+The remaining eight — `info-tech-canon`, `net-kingdom`, `key-cape`,
+`user-engine`, `tenant-engine`, `zone-engine`, `secrets-engine`, `ops-mason`,
+`whitehat-security` — carry a layering review note authored by `gate-house` and
+have not answered it. Those notes state a layer but do not constitute a
+declaration, and this standard does not claim estate-wide adoption on their
+basis. Declaration requests are open as intakes in each.
+
+## 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.
+
+v0.2 → v0.3:
+
+1. **§9.4 added** — approvals assigned to `approval-engine`, with the operative
+   state and the evidence record separated between it and `audit-core`.
+2. **§9.5 added** — graded progression assigned to `maturity-engine`, closing
+   the §9.1 defect in gate-house's own conformance-review claim, and carrying
+   the guardrail that a level may never gate a decision directly.
+3. §4 catalog gained both engines; gate-house's conformance-review claim now
+   names the engine it acts through.
+4. §13 register updated: the approval hole is assigned, two new entries added.
+
+Amended in place while `proposed`, 2026-08-28: §11 gained the who-must-declare
+rule after a conformance sweep found the standard required an `INTENT.md`
+declaration from `OpenBao`, which the estate does not author; and §14 gained the
+honest adoption count.
+
+v0.3 → v0.4:
+
+1. **§4 catalog gained `audit-core`** as an Engine, on its own declaration. v0.3
+   named it as an owner in §9.4 and §13 without cataloguing it — a §11 defect in
+   the standard itself, raised by `audit-core`.
+2. **§9.4 evidence rationale rewritten** to cite `audit-core`'s shipped
+   `docs/integrity.md` bound rather than its INTENT principle 6, and to state
+   that `tamper_evidence` is conditional on live preconditions.
+3. **§9.4 gained emission atomicity** as `approval-engine`'s obligation, and the
+   prohibition on `audit-core` exposing an approval-validity query.
+4. **§9.6 added** — evidence proves alteration and truncation, not omission at
+   source. Estate-wide; the sound and unsound forms of the claim are stated.
+5. **§13** — evidence half recorded as assented with conditions; two new gaps:
+   stronger approval custody (unassigned) and emission atomicity
+   (`approval-engine`).
+
+## 16. Open questions
+
+- Whether approvals warrant archival custody stronger than every other audit
+  source (§13), and if so which mechanism and who owns it.
+- Whether other §4 repositories are missing layer declarations; `audit-core`
+  flagged its own absence and asked whether the catalog needs the same
+  correction elsewhere.
+- Whether the gap register migrates from this standard into `maturity-engine`
+  once that engine exists, leaving the standard to state the rules only.
+- 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.

intakes/intakes.md

@@ -0,0 +1,35 @@
+# Intake records
+
+## NET-IN-0001 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)
+
+```yaml
+id: NET-IN-0001
+kind: intake
+title: 'Declaration requested: state this repository''s layer in INTENT.md (security
+  layer model §11)'
+status: open
+origin: cross-repo
+origin_ref: net-kingdom security-layer-model_v0.4 §11
+priority: low
+owner: net-kingdom
+requested_by: gate-house
+proposed_layer: Taxonomy
+description: 'A conformance sweep on 2026-08-28 found this repository has no layer
+  declaration of its own. It carries a layering review note gate-house wrote into
+  the top of its INTENT.md on 2026-08-24, and that note names a layer — but the words
+  are gate-house''s, sitting above a line admitting the body is unadapted. Section
+  11 has since been amended to say so explicitly: a layer stated about a repository
+  by another repository is not a declaration; only the repository''s own file, in
+  its own voice, conforms. Seven of fifteen estate-authored repositories have declared;
+  this is one of the eight that have not, and the standard does not claim adoption
+  on the basis of notes gate-house wrote. REQUESTED: state the layer in INTENT.md
+  in your own voice, or contest it. PROPOSED LAYER: Taxonomy. NetKingdom standards
+  of record and publication. Note this repository publishes the layer model but has
+  not declared its own place in it. Contesting is a real option and costs nothing
+  — the three repositories that reviewed this model each returned a correction, two
+  of which changed the standard. If the proposed layer is wrong for what this repository
+  actually does, that is more useful to us than a label added to close a checkbox.
+  Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.'
+created: '2026-08-28T21:01:51.894396Z'
+updated: '2026-08-28T21:01:51.894396Z'
+```