---
id: MAT-WP-0001
type: workplan
title: "Stand up maturity-engine on security-layer-model v0.7"
domain: infotech
repo: maturity-engine
status: finished
owner: grok
topic_slug: netkingdom-security-layer-alignment
created: "2026-08-29"
updated: "2026-08-29"
state_hub_workstream_id: "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

```task
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

```task
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

```task
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

```task
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

```task
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

```task
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

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