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

id	type	status	received	reviewed	reviewer	source	consumer	resulting_workplan	standards
MAT-DEMAND-2026-08-29-001	demand-review	accepted	2026-08-29	2026-08-29	grok	operator	maturity-engine maintainers, gate-house, access-engine, kings-guard, ops-warden, net-kingdom	MAT-WP-0001	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.