coulomb/maturity-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Align INTENT and SCOPE with security-layer-model v0.7

Browse source 
Declare Engine/PIP in INTENT frontmatter against the accepted statute
and working companion v0.2. Add SCOPE as the evidenced seed boundary,
a demand review of the remaining seed-to-engine gap, and MAT-WP-0001
to stand up the assessment surface, gap register, and stance-map
inventory the catalog already assigns.

Assistant: grok
Assistant-Session: 01a04ceb-150e-7e80-a542-ec8b1372e164
This commit is contained in:
tegwick 2026-08-29 11:56:26 +02:00
parent 8545e229eb
commit bf0c7d98fd
5 changed files with 800 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

193
INTENT.md
View file

@ -1,13 +1,40 @@
---
layer: Engine
role: PIP
standard: netkingdom-security-layer-model
standard_version: "0.7"
companion: net-kingdom/SECURITY-COMPANION.md
---
# INTENT # INTENT
> **Layer: Engine.** NetKingdom Security Layer Model §4 catalog — a deterministic
> API for a modeled concept, where the same authoritative input state yields the
> same result. Standard: `net-kingdom/canon/standards/security-layer-model_v0.3.md`.
>
> This file captures why this repository exists and the kind of system it is > 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 > meant to become. It is aspirational and stable, not a description of current
> implementation. > 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 ## Purpose
> **maturity-engine computes, deterministically, how far a thing has progressed > **maturity-engine computes, deterministically, how far a thing has progressed
@ -17,19 +44,30 @@
Given the same criteria and the same evidence, it returns the same level. That 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. 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 ## Why This Exists
NetKingdom is full of maturity that nothing owns. NetKingdom is full of maturity that nothing owns.
- The Active Secrets Management Canon defines **ASM-0 … ASM-6**, a seven-level - 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 ladder from *Embedded* to *Closed-Loop Authority*, assessed by hand or not at
at all. all.
- The security layer model has three conformance states — conforming, declared - The security layer model has four conformance states — conforming,
gap, undeclared violation — and a gap register carrying `intended_owner`, blocked-clean, declared gap, undeclared violation — and a gap register
`blocked_on`, and review dates. 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`. - `ops-warden` tracks 27 delegated lanes queryable through `warden route gaps`.
- `kings-guard` holds posture lanes "advisory and fixture-driven until the - `kings-guard` holds posture lanes "advisory and fixture-driven until the
engine gaps close" — a capability at a known level, waiting to climb. 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. - The State Hub carries DoR/DoD/DoC quality debt.
Every one of those is graded progress against criteria with evidence. Each was Every one of those is graded progress against criteria with evidence. Each was
@ -38,7 +76,7 @@ built separately because there was no engine for the concept.
There is also a structural reason. `gate-house` is catalogued as owning There is also a structural reason. `gate-house` is catalogued as owning
**conformance review**, and had no engine to act through — the same defect **conformance review**, and had no engine to act through — the same defect
`kings-guard` found when the catalog assigned it containment while no engine `kings-guard` found when the catalog assigned it containment while no engine
exposed a containment surface (standard §9.1). Staff acts only through 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. APIs; conformance review is Staff work that needs an Engine underneath it.
The split: The split:
@ -62,7 +100,8 @@ 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 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 adaptability is the point, and it is why the approval object — which needs a
closed, binary, replay-proof state machine — belongs to `approval-engine` closed, binary, replay-proof state machine — belongs to `approval-engine`
instead. The two engines are deliberate opposites. instead. The two engines are deliberate opposites and neither may drift toward
the other (statute §9.5).
## What maturity-engine Owns ## What maturity-engine Owns
@ -72,19 +111,33 @@ instead. The two engines are deliberate opposites.
when it goes stale; when it goes stale;
- **level computation** — deterministic, explainable, reproducible from the - **level computation** — deterministic, explainable, reproducible from the
recorded inputs; recorded inputs;
- **the gap register** — declared gaps with `intended_owner`, `blocked_on`, and - **the gap register** — declared gaps and unowned capabilities with
review dates, and the distinction between a tracked gap and an undeclared `capability`, `intended_owner`, `blocked_on`, `review`, `state`, and
violation; 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 - **capability readiness** — whether a catalogued capability has the engine
surface it needs, so a "pending" mark is a queryable fact rather than a surface it needs, so a "pending" mark is a queryable fact rather than a
footnote in a standard; footnote in a standard;
- **progression history** — how a subject moved, when, and on what evidence. - **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 ## What maturity-engine Does Not Own
- **The content of the criteria.** A ladder's levels are authored by whoever owns - **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 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. `ops-warden's`. This engine registers and computes; it does not legislate.
- **Discretionary judgment.** Where deciding whether evidence is adequate needs - **Discretionary judgment.** Where deciding whether evidence is adequate needs
interpretation rather than a rule, that is Staff's call, submitted here as a 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. finding. If a criterion cannot be evaluated by rule, it is not yet a criterion.
@ -93,21 +146,84 @@ instead. The two engines are deliberate opposites.
task list. task list.
- **The evidence archive.** `audit-core` holds the tamper-evident record; this - **The evidence archive.** `audit-core` holds the tamper-evident record; this
engine holds the operative assessment. engine holds the operative assessment.
- **Any authorization decision.** See the guardrail. - **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 ## The Guardrail
> **A maturity level MUST NOT gate a decision directly.** > **A maturity level MUST NOT gate a decision directly.**
Standard §6.1: compiled data that determines an outcome is still deciding, it Statute §6.1 / §9.5: compiled data that determines an outcome is still
just decided earlier. If a level determines whether an action is permitted, it deciding, it just decided earlier. If a level determines whether an action is
must reach `access-engine` as an input claim or a versioned policy rule permitted, it must reach `access-engine` as an input claim or a versioned policy
(standard §6.2) — never by a consumer branching on a level it fetched. 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: 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 *"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. 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 ## Design Principles
1. **Deterministic or it is not a level.** Same criteria, same evidence, same 1. **Deterministic or it is not a level.** Same criteria, same evidence, same
@ -119,8 +235,13 @@ decision point the estate has already ruled against twice.
that only climbs is measuring paperwork. that only climbs is measuring paperwork.
5. **A tracked gap is not conformance.** Declaring a gap makes it visible; it 5. **A tracked gap is not conformance.** Declaring a gap makes it visible; it
never makes it satisfied. never makes it satisfied.
6. **Measure subjects, not people.** Assessments attach to repositories, 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. 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 ## Non-Goals
@ -130,11 +251,17 @@ decision point the estate has already ruled against twice.
is the consumer's decision, subject to the guardrail. is the consumer's decision, subject to the guardrail.
- Not a scorecard for teams or individuals. - Not a scorecard for teams or individuals.
- Not an audit archive. - 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 ## What Would Make This Repository Wrong
- **A consumer branches on a level in the request path.** The guardrail failed - **A consumer branches on a level in the request path.** The guardrail failed
and the estate has a second decision point. 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 - **Criteria become unevaluable prose.** If levels need a human to interpret
them, the engine is a database with opinions and the determinism claim is them, the engine is a database with opinions and the determinism claim is
false. false.
@ -144,6 +271,12 @@ decision point the estate has already ruled against twice.
fed by the systems being assessed, this is a spreadsheet. fed by the systems being assessed, this is a spreadsheet.
- **It absorbs work structure.** Gap register entries start growing owners, - **It absorbs work structure.** Gap register entries start growing owners,
estimates, and due dates until it competes with the State Hub. 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 ## Success Criteria
@ -151,8 +284,16 @@ decision point the estate has already ruled against twice.
reading files, closing the §9.1 defect in its own catalog claim; 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 2. ASM-0…ASM-6 is assessable against a real estate, and the result is
reproducible from recorded evidence; reproducible from recorded evidence;
3. the security layer model's gap register lives here, and `kings-guard`'s 3. the security layer model's gap register lives here, with `state` and
pending containment claim is a queryable fact; owner-status intact, and `kings-guard`'s pending containment claim is a
4. at least two ladders owned by different repositories are registered — the 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; minimum evidence of a model rather than a preference;
5. a subject demonstrably loses a level when its evidence expires. 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.

29
README.md
View file

@ -3,26 +3,31 @@
**Computes, deterministically, how far a thing has progressed against declared **Computes, deterministically, how far a thing has progressed against declared
criteria and submitted evidence — and keeps the history of that progression.** criteria and submitted evidence — and keeps the history of that progression.**
An Engine in the NetKingdom security layer model. Given the same criteria and the An Engine (PIP) in the NetKingdom security layer model v0.7. Given the same
same evidence it returns the same level; that property is what makes it an engine criteria and the same evidence it returns the same level; that property is
rather than an opinion. 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.** > **gate-house judges and proposes. maturity-engine computes and remembers.**
It exists because NetKingdom is full of maturity that nothing owns — the Canon's It exists because NetKingdom is full of maturity that nothing owns — the Canon's
ASM-0…ASM-6 ladder, the layer model's conformance states and gap register, 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, ops-warden's delegated lanes, kings-guard's advisory-until-gaps-close posture,
the State Hub's DoX quality debt — and because `gate-house` was catalogued as PEP stance maps parked in the statute, the State Hub's DoX quality debt — and
owning conformance review with no engine to act through, the same defect because `gate-house` was catalogued as owning conformance review with no engine
kings-guard found for containment. to act through, the same defect kings-guard found for containment.
**Guardrail:** a maturity level must never gate a decision directly. If a level **Guardrail:** a maturity level must never gate a decision directly, and must
determines an outcome it reaches `access-engine` as an input claim, never by a never be compiled into registry content. If a level determines an outcome it
consumer branching on a fetched level. Compiled data that determines an outcome reaches `access-engine` as an input claim or a versioned policy rule, never by
is still deciding. 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 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 fall when evidence expires. The closed, binary, replay-proof state machine of an
approval belongs to `approval-engine`; the two engines are deliberate opposites. approval belongs to `approval-engine`; the two engines are deliberate opposites.
See [INTENT.md](INTENT.md). 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`.

194
SCOPE.md Normal file
View file

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

200
history/260829-demand-netkingdom-security-layer-alignment.md Normal file
View file

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

222
workplans/MAT-WP-0001-netkingdom-security-layer-engine.md Normal file
View file

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