INTENT.md

@@ -1,299 +0,0 @@
----
-layer: Engine
-role: PIP
-standard: netkingdom-security-layer-model
-standard_version: "0.7"
-companion: net-kingdom/SECURITY-COMPANION.md
----
-
-# INTENT
-
-> This file captures why this repository exists and the kind of system it is
-> meant to become. It is aspirational and stable, not a description of current
-> implementation.
-
-> **Layer: Engine. Role: PIP.** This is the declaration required by NetKingdom
-> Security Layer Model v0.7 §11 and the working companion v0.2. It is this
-> repository's own voice, not a catalog row about us. The statute is
-> `net-kingdom/canon/standards/security-layer-model_v0.7.md`; the companion is
-> `net-kingdom/SECURITY-COMPANION.md`. On disagreement the statute governs, and
-> a disagreement is a finding for `gate-house`.
->
-> One test decides the layer: given the same authoritative inputs, do we always
-> return the same result? Yes — same criteria, same evidence, same level. That
-> property is what makes this an Engine rather than an opinion. Companion §1:
-> a new engine is a PIP unless the statute is amended, and statute §6 means it
-> can never be a second PDP. We supply facts a decision consumes as claims.
->
-> **Catalog entry (v0.7 §4):** graded progression against declared criteria and
-> evidence; the gap register; capability readiness (§9.5).
->
-> The machine-readable form required by §11 is `INTENT.md` frontmatter now, and
-> `layer.yaml` once T01 of the alignment workplan lands. Prose cannot
-> distinguish a declaration from a transcribed review; the file is the surface.
->
-> Contest this layer if it is wrong — companion §2 asks for that correction
-> rather than a polite label.
-
-## Purpose
-
-> **maturity-engine computes, deterministically, how far a thing has progressed
-> against declared criteria and submitted evidence — and keeps the history of
-> that progression.**
-
-Given the same criteria and the same evidence, it returns the same level. That
-property is what makes it an Engine rather than an opinion.
-
-Statute §12's self-healing loop has four verbs: observe, evaluate, decide,
-actuate. This repository is **evaluate**. Observation is `kings-guard` and is
-unstaffed. Decision is `access-engine`. Actuation has no surface and is held at
-zero estate-wide. Companion §10: do not plan around observation-in-production
-or automatic containment. Neither is this engine's gap to close.
-
-## Why This Exists
-
-NetKingdom is full of maturity that nothing owns.
-
-- The Active Secrets Management Canon defines **ASM-0 … ASM-6**, a seven-level
-  ladder from *Embedded* to *Closed-Loop Authority*, assessed by hand or not at
-  all.
-- The security layer model has four conformance states — conforming,
-  blocked-clean, declared gap, undeclared violation — and a gap register
-  carrying `intended_owner`, `blocked_on`, `review`, `state`, and owner-status.
-  Statute §13 still holds that table as a snapshot; the snapshot moves here as
-  soon as this engine can store state.
-- `ops-warden` tracks 27 delegated lanes queryable through `warden route gaps`.
-- `kings-guard` holds posture lanes "advisory and fixture-driven until the
-  engine gaps close" — a capability at a known level, waiting to climb.
-- PEP-shaped consumers owe a published unreachable-engine stance map. Until
-  this engine can hold the inventory, statute §13.1 is a one-row register with
-  one absence, which is itself the finding.
-- The State Hub carries DoR/DoD/DoC quality debt.
-
-Every one of those is graded progress against criteria with evidence. Each was
-built separately because there was no engine for the concept.
-
-There is also a structural reason. `gate-house` is catalogued as owning
-**conformance review**, and had no engine to act through — the same defect
-`kings-guard` found when the catalog assigned it containment while no engine
-exposed a containment surface (statute §9.1). Staff acts only through Engine
-APIs; conformance review is Staff work that needs an Engine underneath it.
-
-The split:
-
-> **gate-house judges and proposes. maturity-engine computes and remembers.**
-
-Judgment is inference and belongs to Staff. Computing a level from declared
-criteria and submitted evidence is deterministic and belongs here.
-
-## The Concept
-
-A **maturity model** is a named, versioned ladder: ordered levels, each with
-criteria, each criterion satisfiable by evidence of a declared kind.
-
-An **assessment** binds a subject — a repository, a capability, a lane, a
-tenant, an estate — to a model, a set of submitted evidence, and a computed
-level, at a point in time.
-
-Maturity here is explicitly **not** a lifecycle. It is graded, evidence-based,
-open-ended, and revisable: levels and criteria may be added without breaking
-consumers, and a subject may move down as well as up when evidence expires. That
-adaptability is the point, and it is why the approval object — which needs a
-closed, binary, replay-proof state machine — belongs to `approval-engine`
-instead. The two engines are deliberate opposites and neither may drift toward
-the other (statute §9.5).
-
-## What maturity-engine Owns
-
-- **model registration** — named, versioned ladders with ordered levels and
-  criteria;
-- **evidence submission and validity** — what was submitted, by whom, when, and
-  when it goes stale;
-- **level computation** — deterministic, explainable, reproducible from the
-  recorded inputs;
-- **the gap register** — declared gaps and unowned capabilities with
-  `capability`, `intended_owner`, `blocked_on`, `review`, `state`, and
-  owner-status, and the distinction among conforming, blocked-clean, declared
-  gap, and undeclared violation. Statute §13's table is a snapshot that moves
-  here; the `state` and owner-status columns MUST survive the migration. The
-  three rules that stay in the statute are the two marks (`pending` /
-  `declared-gap`), the owner-status rule (proposed ≠ assigned), and the scoring
-  rule below;
-- **the PEP stance-map inventory** — every PEP-shaped consumer's published
-  unreachable-engine map, currently parked in statute §13.1 until this engine
-  can hold it;
-- **capability readiness** — whether a catalogued capability has the engine
-  surface it needs, so a "pending" mark is a queryable fact rather than a
-  footnote in a standard;
-- **progression history** — how a subject moved, when, and on what evidence;
-- **the claim shape** `access-engine` consumes for a maturity level — a PIP
-  fact, never a decision.
-
-The **gap-record schema** itself is Taxonomy's (statute §17). This engine holds
-the register and computes from records that conform to that schema; it does not
-author the schema.
-
-## What maturity-engine Does Not Own
-
-- **The content of the criteria.** A ladder's levels are authored by whoever owns
-  that doctrine — ASM-0…ASM-6 is `gate-house`'s, workload posture is
-  `ops-warden's`. This engine registers and computes; it does not legislate.
-- **Discretionary judgment.** Where deciding whether evidence is adequate needs
-  interpretation rather than a rule, that is Staff's call, submitted here as a
-  finding. If a criterion cannot be evaluated by rule, it is not yet a criterion.
-- **Work structure.** Workplans and tasks belong to the repository doing the
-  work (ADR-007); `repo-manager` and the State Hub own that. A level is not a
-  task list.
-- **The evidence archive.** `audit-core` holds the tamper-evident record; this
-  engine holds the operative assessment.
-- **Any authorization decision.** See the guardrail. We are a PIP, never a PDP.
-- **Observation in production.** `kings-guard`'s, and currently at zero.
-- **Actuation / containment.** An Engine concept held at zero; not this PIP's
-  surface and not Staff's to own (statute §9.2).
-- **The layering constitution.** `gate-house` authors it; net-kingdom publishes
-  it. We consume it and hold the register the constitution points at.
-- **PEP shape.** Computing a level is not a protected side effect. Stance maps
-  belong to the repositories that cause those effects; we inventory them.
-
-## The Guardrail
-
-> **A maturity level MUST NOT gate a decision directly.**
-
-Statute §6.1 / §9.5: compiled data that determines an outcome is still
-deciding, it just decided earlier. If a level determines whether an action is
-permitted, it must reach `access-engine` as an input claim or a versioned policy
-rule (statute §6.2) — never by a consumer branching on a level it fetched.
-
-> **A maturity level MUST NOT be compiled into registry content.**
-
-Until `access-engine`'s decision provenance carries a registry-snapshot digest
-— a gap it self-declared in §13 — a level reaching a decision through the
-registry is not reconstructable from the decision record. Same constraint, and
-same reason, as zone stance.
-
-This is written on day one because the failure would arrive as a convenience:
-*"we only gate on level ≥ 3, and only for this one lane."* That is the second
-decision point the estate has already ruled against twice.
-
-## Scoring Rule
-
-Statute §11, raised by `kings-guard`: **blocked-clean MUST NOT rank below
-conforming.** A repository that declined a shortcut and left a capability at
-zero has complied at cost. A repository that quietly opened a client and
-declared nothing has not. Any scoring this engine produces — conformance
-review included — MUST keep that order. Ranking restraint as if it were
-non-conformance would punish the repositories that took the standard
-seriously.
-
-The four states, and they are not a ladder of shame:
-
-| State | Meaning |
-| --- | --- |
-| **Conforming** | no Tooling contact, or only declared diagnostic/conduit shapes |
-| **Blocked-clean** | the capability does not exist because no engine exposes it, and there is no Tooling contact |
-| **Declared gap** | a declared Tooling contact — tracked non-conformance |
-| **Undeclared violation** | anything else |
-
-Blocked-clean is not a lesser state than conforming. Declared gap is tracked
-non-conformance, never conformance. An `intended_owner` is a proposal to the
-named repository, not an assignment onto it.
-
-## Evidence Bound
-
-An append-only archive with a verified chain proves records were **not altered
-or truncated after arrival**. It proves nothing about an event never sent
-(statute §9.6 / companion §6). This engine will emit assessment and
-gap-register mutations to `audit-core`.
-
-If a control's soundness depends on a level or a gap-register fact being
-present — because `access-engine` consumes it as a claim — that evidence is
-**load-bearing**: emission MUST be atomic with the state change, queued
-**locally** in this engine's own store, with no synchronous dependency on
-`audit-core` inside the state-change transaction, and a reconciliation or
-heartbeat rather than a rate for rare classes. Otherwise it is attributive:
-seek atomicity, declare the trade if it is given away, and never describe the
-trail as complete.
-
-Absence of a record is not evidence of non-occurrence. Do not cite "observed in
-operation" as evidence while companion §10 holds.
-
-This engine is a PIP. Persistence of models, evidence, assessments, and the
-register is **our own store**, not Lifecycle over catalogued Tooling
-(`OpenBao`, `key-cape`). Uncatalogued clients (State Hub, a future database)
-MUST be listed in the layer declaration so the check is total. The §5 Staff
-binding rule does not apply to an Engine API over state it owns; it does apply
-to any Staff caller of ours.
-
-## Design Principles
-
-1. **Deterministic or it is not a level.** Same criteria, same evidence, same
-   answer, every time.
-2. **Explainable by construction.** Every level comes with the criteria met, the
-   evidence used, and what the next level requires.
-3. **Ladders are data, not code.** A new model is a registration, not a release.
-4. **Levels can fall.** Evidence expires; maturity is not a ratchet, and a model
-   that only climbs is measuring paperwork.
-5. **A tracked gap is not conformance.** Declaring a gap makes it visible; it
-   never makes it satisfied.
-6. **Blocked-clean is compliance at cost.** Never score it below a silent
-   violation.
-7. **Measure subjects, not people.** Assessments attach to repositories,
-   capabilities, and lanes.
-8. **Facts as claims, never as gates.** A consumer that branches on a fetched
-   level has built a second decision point.
-9. **Evaluate; do not observe, decide, or actuate.**
-
-## Non-Goals
-
-- Not a policy decision point, and never one.
-- Not a work tracker, planner, or roadmap.
-- Not a CI gate in itself — it publishes a level; whether anything blocks on it
-  is the consumer's decision, subject to the guardrail.
-- Not a scorecard for teams or individuals.
-- Not an audit archive.
-- Not an observation plane, and not an actuation surface.
-- Not PEP-shaped, and not a publisher of unreachable-engine stance maps.
-
-## What Would Make This Repository Wrong
-
-- **A consumer branches on a level in the request path.** The guardrail failed
-  and the estate has a second decision point.
-- **A level is compiled into registry content** while decision provenance has
-  no snapshot digest. Same failure, earlier.
-- **It starts deciding.** Any endpoint that answers "may this actor do X"
-  rather than "what level is this subject at" is the failure statute §6 names.
-- **Criteria become unevaluable prose.** If levels need a human to interpret
-  them, the engine is a database with opinions and the determinism claim is
-  false.
-- **It only ratchets up.** If no subject ever loses a level, the evidence has no
-  expiry and the model is measuring documents.
-- **Nobody submits evidence.** If assessments are entered by hand rather than
-  fed by the systems being assessed, this is a spreadsheet.
-- **It absorbs work structure.** Gap register entries start growing owners,
-  estimates, and due dates until it competes with the State Hub.
-- **Blocked-clean ranks below conforming.** The scoring rule failed, and
-  restraint is punished.
-- **The register loses `state` or owner-status in the migration.** Proposed
-  becomes assigned by omission.
-- **It claims observation or containment.** Both are estate-wide zeros; citing
-  them as if they worked is a finding.
-
-## Success Criteria
-
-1. `gate-house` performs conformance review through this engine rather than by
-   reading files, closing the §9.1 defect in its own catalog claim;
-2. ASM-0…ASM-6 is assessable against a real estate, and the result is
-   reproducible from recorded evidence;
-3. the security layer model's gap register lives here, with `state` and
-   owner-status intact, and `kings-guard`'s pending containment claim is a
-   queryable fact rather than a footnote;
-4. PEP stance maps are inventoried here, so §13.1 is no longer the estate's
-   real unpublished policy;
-5. at least two ladders owned by different repositories are registered — the
-   minimum evidence of a model rather than a preference;
-6. a subject demonstrably loses a level when its evidence expires;
-7. blocked-clean is never scored below conforming, demonstrated by a test, not
-   by inspection;
-8. a maturity level reaches `access-engine` only as a claim or a versioned
-   policy rule — demonstrated by the absence of a consumer branch and by the
-   claim contract, not by a comment.

README.md

@@ -1,33 +1,3 @@
 # maturity-engine
 
-**Computes, deterministically, how far a thing has progressed against declared
+Modelling, tracking and enabling maturity
-criteria and submitted evidence — and keeps the history of that progression.**
-
-An Engine (PIP) in the NetKingdom security layer model v0.7. Given the same
-criteria and the same evidence it returns the same level; that property is
-what makes it an engine rather than an opinion. It supplies facts a decision
-consumes as claims. It does not decide.
-
-> **gate-house judges and proposes. maturity-engine computes and remembers.**
-
-It exists because NetKingdom is full of maturity that nothing owns — the Canon's
-ASM-0…ASM-6 ladder, the layer model's four conformance states and gap register,
-ops-warden's delegated lanes, kings-guard's advisory-until-gaps-close posture,
-PEP stance maps parked in the statute, the State Hub's DoX quality debt — and
-because `gate-house` was catalogued as owning conformance review with no engine
-to act through, the same defect kings-guard found for containment.
-
-**Guardrail:** a maturity level must never gate a decision directly, and must
-never be compiled into registry content. If a level determines an outcome it
-reaches `access-engine` as an input claim or a versioned policy rule, never by
-a consumer branching on a fetched level. Compiled data that determines an
-outcome is still deciding.
-
-**Scoring:** blocked-clean MUST NOT rank below conforming.
-
-Maturity here is graded, evidence-based, open-ended, and revisable — levels can
-fall when evidence expires. The closed, binary, replay-proof state machine of an
-approval belongs to `approval-engine`; the two engines are deliberate opposites.
-
-This repository is seeded, not yet an engine surface. See [INTENT.md](INTENT.md)
-and [SCOPE.md](SCOPE.md). The work to stand up the surface is `MAT-WP-0001`.

SCOPE.md

@@ -1,194 +0,0 @@
-# SCOPE
-
-> This file describes the repository's current, evidenced responsibility. It is
-> deliberately distinct from the direction in `INTENT.md` and from unreviewed
-> consumer demand.
-
----
-
-## One-liner
-
-Seeded NetKingdom Engine (PIP) for deterministic maturity assessment, the
-estate gap register, and capability readiness — declared in `INTENT.md`,
-not yet implemented.
-
----
-
-## Current Responsibility
-
-`maturity-engine` currently owns the **declaration** of the Engine/PIP
-boundary assigned by NetKingdom Security Layer Model v0.7 §4 and restated
-in `INTENT.md`: graded progression against declared criteria and evidence,
-the gap register, and capability readiness.
-
-It does **not** yet own a running engine, a store, an API, a register that
-can be queried, or a claim contract `access-engine` can consume. Statute
-§13 and §13.1 still hold the gap-register snapshot and the PEP stance-map
-inventory because this repository cannot store state.
-
-This repository now **declares** itself Engine, role PIP, in `INTENT.md`
-frontmatter against security-layer-model v0.7 and companion v0.2. The
-machine-readable `layer.yaml` form, a total client account, and the
-engine surface itself are not yet evidenced here.
-
----
-
-## In Scope
-
-- Declaring this repository's NetKingdom layer and PIP role
-- Named, versioned maturity models (ladders, levels, criteria, evidence kinds)
-- Evidence submission, validity windows, and expiry
-- Deterministic, explainable level computation and progression history
-- The estate gap register (declared contacts and unowned capabilities),
-  including `state` and owner-status
-- Four conformance states and the scoring rule that blocked-clean MUST NOT
-  rank below conforming
-- PEP stance-map inventory
-- Capability-readiness queries (pending / declared-gap / surface exists)
-- The PIP claim shape for a maturity level, consumed by `access-engine`
-- Emission of assessment and register mutations to `audit-core` under the
-  alteration/truncation bound
-- Workplans that close the gap from this seed to the engine `INTENT.md`
-  describes
-
----
-
-## Out of Scope
-
-- Authorization decisions — `access-engine` (the only PDP)
-- Approval objects — `approval-engine`
-- Credential materialization — `secrets-engine`
-- Evidence custody and integrity verification — `audit-core`
-- Security doctrine, ladder *content*, and conformance *judgment* —
-  `gate-house` (Staff acts through this engine; it does not move here)
-- Observation in production — `kings-guard`; currently at zero
-- Actuation / containment — unowned Engine concept held at zero
-- Work structure (workplans, tasks, estimates) of other repositories —
-  those repositories and the State Hub
-- Compiling a level into registry content, or gating a request path on a
-  fetched level
-- PEP stance *maps themselves* — owned by the PEP-shaped consumer;
-  this engine inventories them
-- The gap-record *schema* — Taxonomy (statute §17)
-- The layering constitution — `gate-house` / net-kingdom canon
-- Lifecycle over catalogued Tooling (`OpenBao`, `key-cape`)
-- Scorecards for teams or individuals
-
----
-
-## Authority and Publication Boundaries
-
-| Concern | Authority | Relationship to `maturity-engine` |
-| --- | --- | --- |
-| Layers, one PDP, Staff/Engine binding, evidence bounds | `gate-house` / net-kingdom canon, `security-layer-model` v0.7 | Consumed as the constitution; not redefined here |
-| Operative form of those rules | `net-kingdom/SECURITY-COMPANION.md` v0.2 | Start here; statute governs on disagreement |
-| What this repository owns within Engine/PIP | this repository's `INTENT.md` | Declared; not yet discharged |
-| Whether a request is permitted | `access-engine` | Maturity arrives as a claim or a versioned policy rule |
-| Ladder content (e.g. ASM-0…ASM-6) | the doctrine owner (`gate-house`, `ops-warden`, …) | Registered and computed, not authored |
-| Gap-record schema | Taxonomy (statute §17) | Held as records, not authored |
-| Gap-register snapshot (until we store state) | statute §13 | Migrates here once a store exists |
-| Stance-map inventory (until we store state) | statute §13.1 | Migrates here once a store exists |
-| Evidence archive | `audit-core` | Operative assessment here; archive there |
-| Work indexing | State Hub | Non-catalogued client, listed when used |
-
----
-
-## Relevant When
-
-- Declaring or changing this repository's security layer or PIP role
-- Registering a maturity model or submitting evidence against one
-- Computing or explaining a level for a subject
-- Recording, querying, or reviewing a declared gap or unowned capability
-- Asking whether a catalogued capability has an engine surface
-- Inventorying PEP stance maps
-- Consuming a maturity level as an `access-engine` claim
-- Closing the seed-to-engine gap recorded in
-  `history/260829-demand-netkingdom-security-layer-alignment.md`
-
-## Not Relevant When
-
-- Asking whether an actor may act — that is `access-engine`
-- Asking whether an approval is valid — that is `approval-engine`
-- Writing doctrine or inventing ladder criteria that belong to Staff
-- Assuming observation-in-production or automatic containment exists
-- Tracking work, estimates, or due dates
-- Branching on a fetched level in a request path
-- The request is raw demand that has not yet been reviewed for purpose and
-  scope fit
-
----
-
-## Current State
-
-- Status: seeded, not implemented
-- On disk: `INTENT.md` (v0.7-aligned declaration) and `README.md`
-- Layer declaration: `INTENT.md` frontmatter declares `layer: Engine`,
-  `role: PIP` against security-layer-model v0.7; `layer.yaml` and a
-  conformance check are not yet present
-- Engine surface: none — no API, store, tests, or runtime
-- Gap register: still the statute §13 snapshot
-- Stance-map inventory: still statute §13.1 (one published map, one absence)
-- Claim contract with `access-engine`: not written
-- Evidence emission: not present
-- Registered ladders: none
-- Layout conformance (ITC-REPO-LAYOUT 0.1.0-RC1): **minimal** once this
-  `SCOPE.md` exists; `history/` and `workplans/` are in use as defined,
-  `demand/` and `docs/` are not claimed
-
----
-
-## InfoTechCanon Repository-Layout Alignment
-
-Declared conformance: **`minimal`** under ITC-REPO-LAYOUT 0.1.0-RC1.
-
-- `INTENT.md` contains stable aspiration and boundaries.
-- `SCOPE.md` contains current evidenced responsibility and explicit gaps.
-- `workplans/` contains committed work and remains authoritative for State Hub.
-- `history/` contains dated, inactive reviews.
-
-Intentional omissions:
-
-- `demand/`, `docs/`, `research/`, `spec/`, `wiki/`, and `issues/` are not
-  currently claimed. They should be added only when their distinct semantics
-  are needed, not as empty structural decoration.
-- Finished workplan archival, when it exists, will follow the Custodian
-  ADR-001 convention at `workplans/archived/YYMMDD-...` so State Hub
-  discovery remains deterministic.
-
----
-
-## How It Fits
-
-- Upstream constitution: NetKingdom `security-layer-model` v0.7 and
-  `SECURITY-COMPANION.md` v0.2 (consumed, not authored)
-- Doctrine and conformance judgment: `gate-house`
-- Decision point: `access-engine` (consumes our claims)
-- Opposite engine: `approval-engine` (closed binary object)
-- Evidence archive: `audit-core`
-- Observation (unstaffed): `kings-guard`
-- Coordination/index: State Hub
-- Layout convention: InfoTechCanon repository-layout, level `minimal`
-
----
-
-## Getting Oriented
-
-- Start with: `README.md`, `INTENT.md`, `SCOPE.md`
-- Constitution: `net-kingdom/canon/standards/security-layer-model_v0.7.md`
-- Operative form: `net-kingdom/SECURITY-COMPANION.md`
-- Alignment review:
-  `history/260829-demand-netkingdom-security-layer-alignment.md`
-- Active work: `workplans/`
-
----
-
-## Gap to Intent
-
-The seed declaration is in place. Nothing `INTENT.md` says this engine
-computes, remembers, or inventories is evidenced on disk yet. The work to
-close that gap is `MAT-WP-0001`, sourced from
-`history/260829-demand-netkingdom-security-layer-alignment.md`.
-
-Do not host a PDP, compile a level into a registry, score blocked-clean
-below conforming, or treat observation or containment as available while
-closing it.

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

@@ -1,200 +0,0 @@
----
-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.

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

@@ -1,222 +0,0 @@
----
-id: MAT-WP-0001
-type: workplan
-title: "Stand up maturity-engine on security-layer-model v0.7"
-domain: infotech
-repo: maturity-engine
-status: ready
-owner: grok
-topic_slug: netkingdom-security-layer-alignment
-created: "2026-08-29"
-updated: "2026-08-29"
----
-
-# 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: todo
-priority: high
-```
-
-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: todo
-priority: high
-```
-
-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: todo
-priority: high
-```
-
-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: todo
-priority: high
-```
-
-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: todo
-priority: medium
-```
-
-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: todo
-priority: high
-```
-
-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: todo
-priority: medium
-```
-
-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.