From bf0c7d98fd2acf526cb0df13f59279351b9034ba Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 29 Aug 2026 11:56:26 +0200 Subject: [PATCH] Align INTENT and SCOPE with security-layer-model v0.7 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 --- INTENT.md | 193 +++++++++++++-- README.md | 29 ++- SCOPE.md | 194 +++++++++++++++ ...and-netkingdom-security-layer-alignment.md | 200 ++++++++++++++++ ...P-0001-netkingdom-security-layer-engine.md | 222 ++++++++++++++++++ 5 files changed, 800 insertions(+), 38 deletions(-) create mode 100644 SCOPE.md create mode 100644 history/260829-demand-netkingdom-security-layer-alignment.md create mode 100644 workplans/MAT-WP-0001-netkingdom-security-layer-engine.md diff --git a/INTENT.md b/INTENT.md index 1b09bd5..8728cb6 100644 --- a/INTENT.md +++ b/INTENT.md @@ -1,13 +1,40 @@ +--- +layer: Engine +role: PIP +standard: netkingdom-security-layer-model +standard_version: "0.7" +companion: net-kingdom/SECURITY-COMPANION.md +--- + # 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 > 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 @@ -17,19 +44,30 @@ 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 three conformance states — conforming, declared - gap, undeclared violation — and a gap register carrying `intended_owner`, - `blocked_on`, and review dates. + 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 @@ -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 **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 (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. 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 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. +instead. The two engines are deliberate opposites and neither may drift toward +the other (statute §9.5). ## What maturity-engine Owns @@ -72,19 +111,33 @@ instead. The two engines are deliberate opposites. when it goes stale; - **level computation** — deterministic, explainable, reproducible from the recorded inputs; -- **the gap register** — declared gaps with `intended_owner`, `blocked_on`, and - review dates, and the distinction between a tracked gap and an undeclared - violation; +- **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. +- **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. + `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. @@ -93,21 +146,84 @@ instead. The two engines are deliberate opposites. task list. - **The evidence archive.** `audit-core` holds the tamper-evident record; this 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 > **A maturity level MUST NOT gate a decision directly.** -Standard §6.1: 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 -(standard §6.2) — never by a consumer branching on a level it fetched. +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 @@ -119,8 +235,13 @@ decision point the estate has already ruled against twice. 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. **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. +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 @@ -130,11 +251,17 @@ decision point the estate has already ruled against twice. 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. @@ -144,6 +271,12 @@ decision point the estate has already ruled against twice. 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 @@ -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; 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, and `kings-guard`'s - pending containment claim is a queryable fact; -4. at least two ladders owned by different repositories are registered — the +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; -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. diff --git a/README.md b/README.md index 14eb069..4ca04d7 100644 --- a/README.md +++ b/README.md @@ -3,26 +3,31 @@ **Computes, deterministically, how far a thing has progressed against declared 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 -same evidence it returns the same level; that property is what makes it an engine -rather than an opinion. +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 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, -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. +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. If a level -determines an outcome it reaches `access-engine` as an input claim, never by a -consumer branching on a fetched level. Compiled data that determines an outcome -is still deciding. +**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. -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`. diff --git a/SCOPE.md b/SCOPE.md new file mode 100644 index 0000000..c90a1ea --- /dev/null +++ b/SCOPE.md @@ -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. diff --git a/history/260829-demand-netkingdom-security-layer-alignment.md b/history/260829-demand-netkingdom-security-layer-alignment.md new file mode 100644 index 0000000..3bdac37 --- /dev/null +++ b/history/260829-demand-netkingdom-security-layer-alignment.md @@ -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. diff --git a/workplans/MAT-WP-0001-netkingdom-security-layer-engine.md b/workplans/MAT-WP-0001-netkingdom-security-layer-engine.md new file mode 100644 index 0000000..809e42f --- /dev/null +++ b/workplans/MAT-WP-0001-netkingdom-security-layer-engine.md @@ -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.