maturity-engine/SCOPE.md

# 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.