maturity-engine/workplans/MAT-WP-0001-netkingdom-security-layer-engine.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
MAT-WP-0001	workplan	Stand up maturity-engine on security-layer-model v0.7	infotech	maturity-engine	finished	grok	netkingdom-security-layer-alignment	2026-08-29	2026-08-29	fdc711d0-bcb5-5e40-920c-d608f705f34f

MAT-WP-0001 - Stand up maturity-engine on security-layer-model v0.7

Goal

Make this repository a conforming Engine/PIP under NetKingdom Security Layer Model v0.7: declare the layer in a machine-readable form, stand up the deterministic assessment surface, take the gap register and PEP stance-map inventory off the statute, encode the scoring and guardrail rules as tests, and give gate-house an engine to review through.

Source review: history/260829-demand-netkingdom-security-layer-alignment.md. Statute: net-kingdom/canon/standards/security-layer-model_v0.7.md. Companion: net-kingdom/SECURITY-COMPANION.md v0.2.

Boundaries

• Do not render or cache an authorization decision. We are a PIP.
• Do not compile a maturity level into registry content.
• Do not let a consumer branch on a fetched level; the claim contract is the only sanctioned path into access-engine.
• Do not author ladder criteria. ASM-0…ASM-6 stays gate-house's.
• Do not author the gap-record schema; Taxonomy owns it (statute §17).
• Do not publish a PEP stance map from this repository.
• Do not absorb work structure (owners, estimates, due dates as task fields) into the gap register.
• Do not treat observation-in-production or automatic containment as available, and do not take those zeros as ours to close.
• Do not rank blocked-clean below conforming.
• approval-engine remains the opposite object: closed, binary, replay-proof.
• Persistence is this PIP's own store, not Lifecycle over OpenBao or key-cape.

T01 - Machine-readable layer declaration

id: MAT-WP-0001-T01
status: done
priority: high
state_hub_task_id: "930d9cba-abf5-5982-8f7a-0f8afe518713"

Add layer.yaml in the kings-guard no-contact shape, adapted for Engine/PIP, pointing at security-layer-model v0.7:

• layer: engine
• role: pip
• tooling_contacts: []
• non_tooling_clients lists the State Hub progress/work-record client once it is used
• no pep_stance path
• catalog_entry transcribed from statute §4: graded progression, gap register, capability readiness

INTENT.md frontmatter already declares layer: Engine, role: PIP. Keep the file and the frontmatter equal. A conformance script is optional in this task; the declaration file is the §11 surface.

Done when: layer.yaml is committed, agrees with INTENT.md, and a reviewer can see there are no Tooling contacts and no PEP claim.

T02 - Repository baseline

id: MAT-WP-0001-T02
status: done
priority: high
state_hub_task_id: "a9b019c6-b518-59b1-913a-e47ed8fcc925"

There is no implementation to update. Choose and record:

• language, test harness, and local commands;
• module boundaries for models, evidence, computation, register, claims, and emission;
• the persistence store for this PIP (our own, transactional enough for a local outbox).

Add AGENTS.md (or equivalent) so later sessions can verify changes. Do not pick catalogued Tooling as the store. List any uncatalogued client in layer.yaml when it is introduced.

Done when: a contributor can run a documented test command against a scaffold, and SCOPE's "no runtime" bullet is no longer the whole story.

T03 - Deterministic assessment core

id: MAT-WP-0001-T03
status: done
priority: high
state_hub_task_id: "2b35f065-47fb-5daf-a68d-cf86b8b3d8d7"

Implement the modeled concept:

• named, versioned ladders with ordered levels and criteria;
• evidence submission with validity windows;
• deterministic level computation, explainable by construction (criteria met, evidence used, next level required);
• progression history;
• demotion when evidence expires.

Same criteria and same evidence MUST return the same level. A subject MUST be able to lose a level. Criteria that cannot be evaluated by rule are rejected, not interpreted.

Done when: tests demonstrate determinism, explainability, and expiry demotion from recorded inputs, with no human in the compute path.

T04 - Gap register

id: MAT-WP-0001-T04
status: done
priority: high
state_hub_task_id: "18666e16-a882-571b-a6cc-dee4ddb938eb"

Take statute §13's snapshot into this engine:

• record fields: capability, intended_owner, blocked_on, review, plus state and owner-status (statute §13 / §17);
• two marks: pending and declared-gap;
• owner-status: proposed ≠ assigned;
• four conformance states;
• scoring rule: blocked-clean MUST NOT rank below conforming, asserted by a test.

Seed from the current §13 table. Do not turn register entries into work items. Notify gate-house / net-kingdom so the statute table can become a pointer.

Done when: the §13 rows are queryable here, the two surviving columns are present, the scoring test fails if blocked-clean ranks below conforming, and notice has been sent.

T05 - Stance-map inventory and capability readiness

id: MAT-WP-0001-T05
status: done
priority: medium
state_hub_task_id: "496b98a6-4e28-5d96-a758-1aa8dde7596d"

Take statute §13.1's inventory: every PEP-shaped consumer's published unreachable-engine stance map, including currently unpublished ones (ops-mason). Do not author maps.

Expose capability readiness as a query: pending (no route, no contact), declared-gap (route through a §5.3 contact), or surface exists. This is how kings-guard's pending containment claim becomes a fact rather than a footnote — containment itself stays the unowned actuation surface.

Done when: stance maps are listed here, unpublished PEPs are visible as absences, and a readiness query returns pending / declared-gap / surface-exists without implying ownership of actuation.

T06 - Claim contract, guardrail, evidence emission

id: MAT-WP-0001-T06
status: done
priority: high
state_hub_task_id: "1a606ac1-1b02-5b33-a8c3-79f6f45a841f"

Publish the PIP claim shape access-engine consumes for a maturity level. Bind:

• levels arrive as request claims or versioned policy rules (statute §6.2 / §9.5);
• a level MUST NOT be compiled into registry content;
• a consumer MUST NOT branch on a fetched level.

Emit assessment and register mutations to audit-core. Queue locally in this engine's store. No synchronous audit-core dependency inside the state-change transaction. Classify load-bearing vs attributive once a claim is actually consumed; rare load-bearing classes need reconciliation or a heartbeat, not a rate.

Done when: the claim contract is in-repo, guardrail tests reject a registry compile and a consumer branch, and emission is queued locally with the §9.6 bound stated next to the trail.

T07 - First ladders, review path, SCOPE closeout

id: MAT-WP-0001-T07
status: done
priority: medium
state_hub_task_id: "e476cc41-0a9d-59e5-b2e1-44f974997acd"

Register at least two ladders owned by different repositories. The first is ASM-0…ASM-6; content remains gate-house's. The second proves this is a model rather than a preference.

Expose the surface gate-house uses for conformance review — compute and remember, not judge.

After T01–T06, refresh SCOPE.md Current State and Gap to Intent so they describe evidenced artifacts rather than the 2026-08-29 seed deficit. Keep Intent aspirational. Do not mark this workplan finished while T03 and T04 are open.

Done when: two ladders are registered, gate-house can review through this engine rather than by reading files, SCOPE matches the files on disk, and this workplan can move to finished without leaving silent follow-on work that still belongs to the seed-to-engine gap.

Sequencing

T01 can proceed immediately. T02 unblocks T03–T06. T03 and T04 are the load-bearing pair; T05 may proceed once the store from T02 exists. T06 needs T03. T07 is last.