maturity-engine/history/260829-demand-netkingdom-security-layer-alignment.md

---
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.