--- id: MAT-DEMAND-2026-08-29-001 type: demand-review status: accepted received: "2026-08-29" reviewed: "2026-08-29" reviewer: grok source: operator consumer: maturity-engine maintainers, gate-house, access-engine, kings-guard, ops-warden, net-kingdom resulting_workplan: MAT-WP-0001 standards: - net-kingdom/canon/standards/security-layer-model_v0.7.md - net-kingdom/SECURITY-COMPANION.md --- # Review: align maturity-engine with the NetKingdom security-layer model ## Demand signal The NetKingdom security-layer standard has been finalized as **accepted v0.7** (2026-08-29) and complemented by **working companion v0.2**. Read the latest text, adapt `INTENT.md`, update `SCOPE.md`, assess remaining gaps between intent and current implementation, and open a workplan for the evolution this repository still owes. ## Consumer purpose Maintainers and the Staff/Engine neighbours need to tell, without reconstructing context from `gate-house` notes: - which NetKingdom layer and engine role this repository occupies; - that it is the evaluate verb in the self-healing loop, not observe / decide / actuate; - which objects it will compute and remember (levels, the gap register, capability readiness, the stance-map inventory); - which guardrails bind every consumer (no direct gate, no registry compile, blocked-clean not ranked below conforming); - which implementation work belongs here versus in `access-engine`, `approval-engine`, `audit-core`, `gate-house`, or `kings-guard`. ## Purpose fit **Strong fit.** Statute §4 already catalogues this repository as Engine / PIP owning graded progression, the gap register, and capability readiness (§9.5). Companion §1–§2 require a layer declaration in our own voice. Statute §13 and §13.1 name this engine as the destination of the gap register and the PEP stance-map inventory. Aligning intent and scope, then standing up the surface those sections point at, is this repository's job. Rendering decisions, writing doctrine, observing production, or actuating containment is not. ## Evidence reviewed - `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted; §2–§6, §9.1–§9.6, §11–§13.1, §14, §16–§17) - `net-kingdom/SECURITY-COMPANION.md` v0.2 (operative form; §1–§3, §6, §8, §10) - `net-kingdom/history/2026-08-29-layering-standard-assessment.md` (evaluate verb; register must leave the statute) - Seed `INTENT.md` (v0.3-era declaration, no frontmatter, no PIP role, no scoring rule, no stance-map inventory, no registry-compile prohibition) - Seed `README.md` - On-disk tree: two files, no `SCOPE.md`, no `layer.yaml`, no code, no tests - Reference declarations: `ops-warden/layer.yaml`, `kings-guard/layer.yaml` - Adjacent seed: `approval-engine/INTENT.md` (deliberate opposite) - Layout convention: ITC-REPO-LAYOUT 0.1.0-RC1 ## What the standard requires of this repository Companion §2 / statute §11: declare `layer:` and, as an Engine, `role:` in our own `INTENT.md`, in a machine-readable form. A catalog row or a review note about us is not a declaration. Statute §14 already listed this repository among the seven that had declared in their own voice against an earlier version; that listing is not a v0.7 declaration. Companion §1 / statute §3.3: **PIP**. Same inputs, same result. A new engine is a PIP unless the statute is amended. Never a second PDP. Statute §9.5: 1. Deterministic level from criteria and evidence. 2. `gate-house` judges and proposes; this engine computes and remembers. 3. A maturity level MUST NOT be compiled into registry content. 4. A maturity level MUST NOT gate a decision directly; it reaches `access-engine` as a claim or a versioned policy rule. 5. Approvals and maturity stay deliberate opposites. Statute §11 scoring rule: any scoring we produce MUST NOT rank blocked-clean below conforming. Statute §13: the gap-register table is a snapshot that moves here as soon as we can store state. `state` and owner-status MUST survive. Three rules stay in the statute: the two marks, proposed ≠ assigned, and the scoring rule. Statute §13.1 / §6.4: hold the PEP stance-map inventory once we can. Statute §12 / companion §10: we are evaluate. Do not plan around observation-in-production or automatic containment. Statute §9.6 / companion §6: emit under the alteration/truncation bound; load-bearing facts need a local outbox and a heartbeat or reconciliation. Statute §17: the gap-record schema is Taxonomy's; we hold conforming records. Companion §8: four conformance states, including blocked-clean as not-worse than conforming. ## Layer chosen **Engine**, **role: PIP**. The companion §1 test holds: a deterministic API for one modeled concept. The catalog row matches. We do not contest it. This repository is **not PEP-shaped**. Computing a level does not cause a protected side effect. We inventory other people's stance maps; we do not publish one of our own. Persistence, when it exists, is this PIP's own store, not Lifecycle over `OpenBao` or `key-cape`. Uncatalogued clients (State Hub, a future database) must be listed so the check is total. ## Scope versus intent | Intent (after this alignment) | Current evidenced scope | Gap | | --- | --- | --- | | Declare `layer: Engine`, `role: PIP` in our own voice | Frontmatter now present in `INTENT.md` | Machine-readable `layer.yaml` and a conformance check, as in the `kings-guard` no-contact form adapted for an Engine, are missing | | Total account of clients | No runtime clients exist | State Hub writes will exist as soon as work is registered; list them when they do. A future store is a non-Tooling client until catalogued | | Deterministic assessment API (models, evidence, compute, explain, history) | None | Seed-to-engine; the catalog currently assigns a capability with no surface — the §9.1 defect this engine was created to close, still open on our side | | Levels can fall when evidence expires | None | Must be in the first computation contract, not bolted on | | Gap register migrates from statute §13 with `state` and owner-status | Statute still holds the snapshot | Take the snapshot; keep the three surviving rules in the statute; notify `gate-house` so §13 can become a pointer | | Four conformance states; blocked-clean MUST NOT rank below conforming | Stated in INTENT; no scorer exists | Encode as a test, not a comment, before the first conformance review | | PEP stance-map inventory | Statute §13.1, one row plus an absence | Take the inventory; do not author maps | | Capability readiness as a queryable fact | Catalog footnotes and `kings-guard` pending marks | Query surface for pending / declared-gap / surface-exists | | Claim contract with `access-engine`; no registry compile; no direct gate | Guardrail is prose only | Written contract plus tests that a consumer branch and a registry compile are out of contract | | Evidence emission to `audit-core` under §9.6 | None | Local outbox; classify load-bearing vs attributive once claims are consumed | | `gate-house` conformance review through this engine | `gate-house` still reads files | Review API after computation and register exist | | ASM-0…ASM-6 assessable; two ladders from different owners | No models registered | Content stays with doctrine owners; registration is ours | | Do not observe, decide, or actuate | True: no such surfaces | Keep it; companion §10 | | Do not host a PDP, approval store, credential plane, or evidence archive | True: no surfaces at all | Keep it | ## What is already aligned - The concept (graded, evidence-based, open-ended, revisable) and the split with `gate-house` were correct in the v0.3 seed and survive v0.7. - The split with `approval-engine` is restated in statute §9.5; no rewrite of the object of the architecture is required. - The "never gate a decision directly" guardrail was already in the seed; v0.7 adds the registry-compile prohibition and the PIP typing around it. - This repo does not implement Staff judgment, a PDP, observation, or actuation, because it implements nothing yet — restraint by vacancy, which is the correct vacancy. ## What must not be done here - Do not become a second decision point, including by compiling a level into a registry or by letting a consumer branch on a fetched level. - Do not author ladder criteria that belong to `gate-house` or `ops-warden`. - Do not take the gap-record schema away from Taxonomy. - Do not publish a PEP stance map from this repository. - Do not absorb work structure into the gap register. - Do not treat observation-in-production or automatic containment as available, and do not take those gaps as ours to close. - Do not emit synchronously to `audit-core` inside a state-change transaction if a level or gap fact is load-bearing. - Do not rank blocked-clean below conforming in any scorer. ## Necessities for the current implementation Ordered by what this repository can close without pretending to own a PDP: 1. **Machine-readable declaration.** `layer.yaml` in the kings-guard no-contact shape adapted for Engine/PIP: empty `tooling_contacts`, State Hub listed under `non_tooling_clients` once used, no `pep_stance` path, catalog owns transcribed from §4. `INTENT.md` frontmatter already declares the layer. Keep the file and the frontmatter equal. 2. **Repository baseline.** Layout, stack, test harness, persistence choice. There is no implementation to "update"; there is one to start. 3. **Deterministic assessment core.** Models, evidence, computation, explainability, history, expiry. Same inputs, same level, with a test that a subject loses a level when evidence expires. 4. **Gap register.** Schema fields from statute §17 plus `state` and owner-status; seed from the §13 snapshot; four conformance states; scoring rule as a test. Then notice `gate-house` / `net-kingdom`. 5. **Stance-map inventory and capability readiness.** Take §13.1; expose pending / declared-gap / surface-exists as queries. 6. **Claim contract, guardrail tests, evidence emission.** Levels as claims; no registry compile; local outbox. 7. **First two ladders and the gate-house review path.** ASM content remains `gate-house`'s. A second ladder from a different owner is the minimum evidence this is a model. Refresh `SCOPE.md` against evidenced artifacts when those land. ## Disposition **Accepted** as `MAT-WP-0001`. The work belongs here because statute §4, §9.5, §13, and §13.1 already name this repository as the owner of the missing surfaces. Engine implementation is in-scope. PDP behaviour, doctrine authorship, observation, and actuation are routed outward.