diff --git a/INTENT.md b/INTENT.md deleted file mode 100644 index 8728cb6..0000000 --- a/INTENT.md +++ /dev/null @@ -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. diff --git a/README.md b/README.md index 4ca04d7..c20aa7e 100644 --- a/README.md +++ b/README.md @@ -1,33 +1,3 @@ # maturity-engine -**Computes, deterministically, how far a thing has progressed against declared -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`. +Modelling, tracking and enabling maturity \ No newline at end of file diff --git a/SCOPE.md b/SCOPE.md deleted file mode 100644 index c90a1ea..0000000 --- a/SCOPE.md +++ /dev/null @@ -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. diff --git a/history/260829-demand-netkingdom-security-layer-alignment.md b/history/260829-demand-netkingdom-security-layer-alignment.md deleted file mode 100644 index 3bdac37..0000000 --- a/history/260829-demand-netkingdom-security-layer-alignment.md +++ /dev/null @@ -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. diff --git a/workplans/MAT-WP-0001-netkingdom-security-layer-engine.md b/workplans/MAT-WP-0001-netkingdom-security-layer-engine.md deleted file mode 100644 index 809e42f..0000000 --- a/workplans/MAT-WP-0001-netkingdom-security-layer-engine.md +++ /dev/null @@ -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.