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