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
This commit is contained in:
parent
8545e229eb
commit
bf0c7d98fd
5 changed files with 800 additions and 38 deletions
193
INTENT.md
193
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.
|
||||
|
|
|
|||
29
README.md
29
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`.
|
||||
|
|
|
|||
194
SCOPE.md
Normal file
194
SCOPE.md
Normal file
|
|
@ -0,0 +1,194 @@
|
|||
# SCOPE
|
||||
|
||||
> This file describes the repository's current, evidenced responsibility. It is
|
||||
> deliberately distinct from the direction in `INTENT.md` and from unreviewed
|
||||
> consumer demand.
|
||||
|
||||
---
|
||||
|
||||
## One-liner
|
||||
|
||||
Seeded NetKingdom Engine (PIP) for deterministic maturity assessment, the
|
||||
estate gap register, and capability readiness — declared in `INTENT.md`,
|
||||
not yet implemented.
|
||||
|
||||
---
|
||||
|
||||
## Current Responsibility
|
||||
|
||||
`maturity-engine` currently owns the **declaration** of the Engine/PIP
|
||||
boundary assigned by NetKingdom Security Layer Model v0.7 §4 and restated
|
||||
in `INTENT.md`: graded progression against declared criteria and evidence,
|
||||
the gap register, and capability readiness.
|
||||
|
||||
It does **not** yet own a running engine, a store, an API, a register that
|
||||
can be queried, or a claim contract `access-engine` can consume. Statute
|
||||
§13 and §13.1 still hold the gap-register snapshot and the PEP stance-map
|
||||
inventory because this repository cannot store state.
|
||||
|
||||
This repository now **declares** itself Engine, role PIP, in `INTENT.md`
|
||||
frontmatter against security-layer-model v0.7 and companion v0.2. The
|
||||
machine-readable `layer.yaml` form, a total client account, and the
|
||||
engine surface itself are not yet evidenced here.
|
||||
|
||||
---
|
||||
|
||||
## In Scope
|
||||
|
||||
- Declaring this repository's NetKingdom layer and PIP role
|
||||
- Named, versioned maturity models (ladders, levels, criteria, evidence kinds)
|
||||
- Evidence submission, validity windows, and expiry
|
||||
- Deterministic, explainable level computation and progression history
|
||||
- The estate gap register (declared contacts and unowned capabilities),
|
||||
including `state` and owner-status
|
||||
- Four conformance states and the scoring rule that blocked-clean MUST NOT
|
||||
rank below conforming
|
||||
- PEP stance-map inventory
|
||||
- Capability-readiness queries (pending / declared-gap / surface exists)
|
||||
- The PIP claim shape for a maturity level, consumed by `access-engine`
|
||||
- Emission of assessment and register mutations to `audit-core` under the
|
||||
alteration/truncation bound
|
||||
- Workplans that close the gap from this seed to the engine `INTENT.md`
|
||||
describes
|
||||
|
||||
---
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- Authorization decisions — `access-engine` (the only PDP)
|
||||
- Approval objects — `approval-engine`
|
||||
- Credential materialization — `secrets-engine`
|
||||
- Evidence custody and integrity verification — `audit-core`
|
||||
- Security doctrine, ladder *content*, and conformance *judgment* —
|
||||
`gate-house` (Staff acts through this engine; it does not move here)
|
||||
- Observation in production — `kings-guard`; currently at zero
|
||||
- Actuation / containment — unowned Engine concept held at zero
|
||||
- Work structure (workplans, tasks, estimates) of other repositories —
|
||||
those repositories and the State Hub
|
||||
- Compiling a level into registry content, or gating a request path on a
|
||||
fetched level
|
||||
- PEP stance *maps themselves* — owned by the PEP-shaped consumer;
|
||||
this engine inventories them
|
||||
- The gap-record *schema* — Taxonomy (statute §17)
|
||||
- The layering constitution — `gate-house` / net-kingdom canon
|
||||
- Lifecycle over catalogued Tooling (`OpenBao`, `key-cape`)
|
||||
- Scorecards for teams or individuals
|
||||
|
||||
---
|
||||
|
||||
## Authority and Publication Boundaries
|
||||
|
||||
| Concern | Authority | Relationship to `maturity-engine` |
|
||||
| --- | --- | --- |
|
||||
| Layers, one PDP, Staff/Engine binding, evidence bounds | `gate-house` / net-kingdom canon, `security-layer-model` v0.7 | Consumed as the constitution; not redefined here |
|
||||
| Operative form of those rules | `net-kingdom/SECURITY-COMPANION.md` v0.2 | Start here; statute governs on disagreement |
|
||||
| What this repository owns within Engine/PIP | this repository's `INTENT.md` | Declared; not yet discharged |
|
||||
| Whether a request is permitted | `access-engine` | Maturity arrives as a claim or a versioned policy rule |
|
||||
| Ladder content (e.g. ASM-0…ASM-6) | the doctrine owner (`gate-house`, `ops-warden`, …) | Registered and computed, not authored |
|
||||
| Gap-record schema | Taxonomy (statute §17) | Held as records, not authored |
|
||||
| Gap-register snapshot (until we store state) | statute §13 | Migrates here once a store exists |
|
||||
| Stance-map inventory (until we store state) | statute §13.1 | Migrates here once a store exists |
|
||||
| Evidence archive | `audit-core` | Operative assessment here; archive there |
|
||||
| Work indexing | State Hub | Non-catalogued client, listed when used |
|
||||
|
||||
---
|
||||
|
||||
## Relevant When
|
||||
|
||||
- Declaring or changing this repository's security layer or PIP role
|
||||
- Registering a maturity model or submitting evidence against one
|
||||
- Computing or explaining a level for a subject
|
||||
- Recording, querying, or reviewing a declared gap or unowned capability
|
||||
- Asking whether a catalogued capability has an engine surface
|
||||
- Inventorying PEP stance maps
|
||||
- Consuming a maturity level as an `access-engine` claim
|
||||
- Closing the seed-to-engine gap recorded in
|
||||
`history/260829-demand-netkingdom-security-layer-alignment.md`
|
||||
|
||||
## Not Relevant When
|
||||
|
||||
- Asking whether an actor may act — that is `access-engine`
|
||||
- Asking whether an approval is valid — that is `approval-engine`
|
||||
- Writing doctrine or inventing ladder criteria that belong to Staff
|
||||
- Assuming observation-in-production or automatic containment exists
|
||||
- Tracking work, estimates, or due dates
|
||||
- Branching on a fetched level in a request path
|
||||
- The request is raw demand that has not yet been reviewed for purpose and
|
||||
scope fit
|
||||
|
||||
---
|
||||
|
||||
## Current State
|
||||
|
||||
- Status: seeded, not implemented
|
||||
- On disk: `INTENT.md` (v0.7-aligned declaration) and `README.md`
|
||||
- Layer declaration: `INTENT.md` frontmatter declares `layer: Engine`,
|
||||
`role: PIP` against security-layer-model v0.7; `layer.yaml` and a
|
||||
conformance check are not yet present
|
||||
- Engine surface: none — no API, store, tests, or runtime
|
||||
- Gap register: still the statute §13 snapshot
|
||||
- Stance-map inventory: still statute §13.1 (one published map, one absence)
|
||||
- Claim contract with `access-engine`: not written
|
||||
- Evidence emission: not present
|
||||
- Registered ladders: none
|
||||
- Layout conformance (ITC-REPO-LAYOUT 0.1.0-RC1): **minimal** once this
|
||||
`SCOPE.md` exists; `history/` and `workplans/` are in use as defined,
|
||||
`demand/` and `docs/` are not claimed
|
||||
|
||||
---
|
||||
|
||||
## InfoTechCanon Repository-Layout Alignment
|
||||
|
||||
Declared conformance: **`minimal`** under ITC-REPO-LAYOUT 0.1.0-RC1.
|
||||
|
||||
- `INTENT.md` contains stable aspiration and boundaries.
|
||||
- `SCOPE.md` contains current evidenced responsibility and explicit gaps.
|
||||
- `workplans/` contains committed work and remains authoritative for State Hub.
|
||||
- `history/` contains dated, inactive reviews.
|
||||
|
||||
Intentional omissions:
|
||||
|
||||
- `demand/`, `docs/`, `research/`, `spec/`, `wiki/`, and `issues/` are not
|
||||
currently claimed. They should be added only when their distinct semantics
|
||||
are needed, not as empty structural decoration.
|
||||
- Finished workplan archival, when it exists, will follow the Custodian
|
||||
ADR-001 convention at `workplans/archived/YYMMDD-...` so State Hub
|
||||
discovery remains deterministic.
|
||||
|
||||
---
|
||||
|
||||
## How It Fits
|
||||
|
||||
- Upstream constitution: NetKingdom `security-layer-model` v0.7 and
|
||||
`SECURITY-COMPANION.md` v0.2 (consumed, not authored)
|
||||
- Doctrine and conformance judgment: `gate-house`
|
||||
- Decision point: `access-engine` (consumes our claims)
|
||||
- Opposite engine: `approval-engine` (closed binary object)
|
||||
- Evidence archive: `audit-core`
|
||||
- Observation (unstaffed): `kings-guard`
|
||||
- Coordination/index: State Hub
|
||||
- Layout convention: InfoTechCanon repository-layout, level `minimal`
|
||||
|
||||
---
|
||||
|
||||
## Getting Oriented
|
||||
|
||||
- Start with: `README.md`, `INTENT.md`, `SCOPE.md`
|
||||
- Constitution: `net-kingdom/canon/standards/security-layer-model_v0.7.md`
|
||||
- Operative form: `net-kingdom/SECURITY-COMPANION.md`
|
||||
- Alignment review:
|
||||
`history/260829-demand-netkingdom-security-layer-alignment.md`
|
||||
- Active work: `workplans/`
|
||||
|
||||
---
|
||||
|
||||
## Gap to Intent
|
||||
|
||||
The seed declaration is in place. Nothing `INTENT.md` says this engine
|
||||
computes, remembers, or inventories is evidenced on disk yet. The work to
|
||||
close that gap is `MAT-WP-0001`, sourced from
|
||||
`history/260829-demand-netkingdom-security-layer-alignment.md`.
|
||||
|
||||
Do not host a PDP, compile a level into a registry, score blocked-clean
|
||||
below conforming, or treat observation or containment as available while
|
||||
closing it.
|
||||
200
history/260829-demand-netkingdom-security-layer-alignment.md
Normal file
200
history/260829-demand-netkingdom-security-layer-alignment.md
Normal file
|
|
@ -0,0 +1,200 @@
|
|||
---
|
||||
id: MAT-DEMAND-2026-08-29-001
|
||||
type: demand-review
|
||||
status: accepted
|
||||
received: "2026-08-29"
|
||||
reviewed: "2026-08-29"
|
||||
reviewer: grok
|
||||
source: operator
|
||||
consumer: maturity-engine maintainers, gate-house, access-engine, kings-guard, ops-warden, net-kingdom
|
||||
resulting_workplan: MAT-WP-0001
|
||||
standards:
|
||||
- net-kingdom/canon/standards/security-layer-model_v0.7.md
|
||||
- net-kingdom/SECURITY-COMPANION.md
|
||||
---
|
||||
|
||||
# Review: align maturity-engine with the NetKingdom security-layer model
|
||||
|
||||
## Demand signal
|
||||
|
||||
The NetKingdom security-layer standard has been finalized as **accepted v0.7**
|
||||
(2026-08-29) and complemented by **working companion v0.2**. Read the latest
|
||||
text, adapt `INTENT.md`, update `SCOPE.md`, assess remaining gaps between
|
||||
intent and current implementation, and open a workplan for the evolution this
|
||||
repository still owes.
|
||||
|
||||
## Consumer purpose
|
||||
|
||||
Maintainers and the Staff/Engine neighbours need to tell, without
|
||||
reconstructing context from `gate-house` notes:
|
||||
|
||||
- which NetKingdom layer and engine role this repository occupies;
|
||||
- that it is the evaluate verb in the self-healing loop, not observe /
|
||||
decide / actuate;
|
||||
- which objects it will compute and remember (levels, the gap register,
|
||||
capability readiness, the stance-map inventory);
|
||||
- which guardrails bind every consumer (no direct gate, no registry compile,
|
||||
blocked-clean not ranked below conforming);
|
||||
- which implementation work belongs here versus in `access-engine`,
|
||||
`approval-engine`, `audit-core`, `gate-house`, or `kings-guard`.
|
||||
|
||||
## Purpose fit
|
||||
|
||||
**Strong fit.** Statute §4 already catalogues this repository as Engine /
|
||||
PIP owning graded progression, the gap register, and capability readiness
|
||||
(§9.5). Companion §1–§2 require a layer declaration in our own voice.
|
||||
Statute §13 and §13.1 name this engine as the destination of the gap
|
||||
register and the PEP stance-map inventory. Aligning intent and scope, then
|
||||
standing up the surface those sections point at, is this repository's job.
|
||||
Rendering decisions, writing doctrine, observing production, or actuating
|
||||
containment is not.
|
||||
|
||||
## Evidence reviewed
|
||||
|
||||
- `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted; §2–§6,
|
||||
§9.1–§9.6, §11–§13.1, §14, §16–§17)
|
||||
- `net-kingdom/SECURITY-COMPANION.md` v0.2 (operative form; §1–§3, §6, §8, §10)
|
||||
- `net-kingdom/history/2026-08-29-layering-standard-assessment.md` (evaluate
|
||||
verb; register must leave the statute)
|
||||
- Seed `INTENT.md` (v0.3-era declaration, no frontmatter, no PIP role, no
|
||||
scoring rule, no stance-map inventory, no registry-compile prohibition)
|
||||
- Seed `README.md`
|
||||
- On-disk tree: two files, no `SCOPE.md`, no `layer.yaml`, no code, no tests
|
||||
- Reference declarations: `ops-warden/layer.yaml`, `kings-guard/layer.yaml`
|
||||
- Adjacent seed: `approval-engine/INTENT.md` (deliberate opposite)
|
||||
- Layout convention: ITC-REPO-LAYOUT 0.1.0-RC1
|
||||
|
||||
## What the standard requires of this repository
|
||||
|
||||
Companion §2 / statute §11: declare `layer:` and, as an Engine, `role:` in
|
||||
our own `INTENT.md`, in a machine-readable form. A catalog row or a review
|
||||
note about us is not a declaration. Statute §14 already listed this
|
||||
repository among the seven that had declared in their own voice against an
|
||||
earlier version; that listing is not a v0.7 declaration.
|
||||
|
||||
Companion §1 / statute §3.3: **PIP**. Same inputs, same result. A new engine
|
||||
is a PIP unless the statute is amended. Never a second PDP.
|
||||
|
||||
Statute §9.5:
|
||||
|
||||
1. Deterministic level from criteria and evidence.
|
||||
2. `gate-house` judges and proposes; this engine computes and remembers.
|
||||
3. A maturity level MUST NOT be compiled into registry content.
|
||||
4. A maturity level MUST NOT gate a decision directly; it reaches
|
||||
`access-engine` as a claim or a versioned policy rule.
|
||||
5. Approvals and maturity stay deliberate opposites.
|
||||
|
||||
Statute §11 scoring rule: any scoring we produce MUST NOT rank blocked-clean
|
||||
below conforming.
|
||||
|
||||
Statute §13: the gap-register table is a snapshot that moves here as soon as
|
||||
we can store state. `state` and owner-status MUST survive. Three rules stay
|
||||
in the statute: the two marks, proposed ≠ assigned, and the scoring rule.
|
||||
|
||||
Statute §13.1 / §6.4: hold the PEP stance-map inventory once we can.
|
||||
|
||||
Statute §12 / companion §10: we are evaluate. Do not plan around
|
||||
observation-in-production or automatic containment.
|
||||
|
||||
Statute §9.6 / companion §6: emit under the alteration/truncation bound;
|
||||
load-bearing facts need a local outbox and a heartbeat or reconciliation.
|
||||
|
||||
Statute §17: the gap-record schema is Taxonomy's; we hold conforming records.
|
||||
|
||||
Companion §8: four conformance states, including blocked-clean as not-worse
|
||||
than conforming.
|
||||
|
||||
## Layer chosen
|
||||
|
||||
**Engine**, **role: PIP**.
|
||||
|
||||
The companion §1 test holds: a deterministic API for one modeled concept.
|
||||
The catalog row matches. We do not contest it.
|
||||
|
||||
This repository is **not PEP-shaped**. Computing a level does not cause a
|
||||
protected side effect. We inventory other people's stance maps; we do not
|
||||
publish one of our own.
|
||||
|
||||
Persistence, when it exists, is this PIP's own store, not Lifecycle over
|
||||
`OpenBao` or `key-cape`. Uncatalogued clients (State Hub, a future database)
|
||||
must be listed so the check is total.
|
||||
|
||||
## Scope versus intent
|
||||
|
||||
| Intent (after this alignment) | Current evidenced scope | Gap |
|
||||
| --- | --- | --- |
|
||||
| Declare `layer: Engine`, `role: PIP` in our own voice | Frontmatter now present in `INTENT.md` | Machine-readable `layer.yaml` and a conformance check, as in the `kings-guard` no-contact form adapted for an Engine, are missing |
|
||||
| Total account of clients | No runtime clients exist | State Hub writes will exist as soon as work is registered; list them when they do. A future store is a non-Tooling client until catalogued |
|
||||
| Deterministic assessment API (models, evidence, compute, explain, history) | None | Seed-to-engine; the catalog currently assigns a capability with no surface — the §9.1 defect this engine was created to close, still open on our side |
|
||||
| Levels can fall when evidence expires | None | Must be in the first computation contract, not bolted on |
|
||||
| Gap register migrates from statute §13 with `state` and owner-status | Statute still holds the snapshot | Take the snapshot; keep the three surviving rules in the statute; notify `gate-house` so §13 can become a pointer |
|
||||
| Four conformance states; blocked-clean MUST NOT rank below conforming | Stated in INTENT; no scorer exists | Encode as a test, not a comment, before the first conformance review |
|
||||
| PEP stance-map inventory | Statute §13.1, one row plus an absence | Take the inventory; do not author maps |
|
||||
| Capability readiness as a queryable fact | Catalog footnotes and `kings-guard` pending marks | Query surface for pending / declared-gap / surface-exists |
|
||||
| Claim contract with `access-engine`; no registry compile; no direct gate | Guardrail is prose only | Written contract plus tests that a consumer branch and a registry compile are out of contract |
|
||||
| Evidence emission to `audit-core` under §9.6 | None | Local outbox; classify load-bearing vs attributive once claims are consumed |
|
||||
| `gate-house` conformance review through this engine | `gate-house` still reads files | Review API after computation and register exist |
|
||||
| ASM-0…ASM-6 assessable; two ladders from different owners | No models registered | Content stays with doctrine owners; registration is ours |
|
||||
| Do not observe, decide, or actuate | True: no such surfaces | Keep it; companion §10 |
|
||||
| Do not host a PDP, approval store, credential plane, or evidence archive | True: no surfaces at all | Keep it |
|
||||
|
||||
## What is already aligned
|
||||
|
||||
- The concept (graded, evidence-based, open-ended, revisable) and the
|
||||
split with `gate-house` were correct in the v0.3 seed and survive v0.7.
|
||||
- The split with `approval-engine` is restated in statute §9.5; no rewrite
|
||||
of the object of the architecture is required.
|
||||
- The "never gate a decision directly" guardrail was already in the seed;
|
||||
v0.7 adds the registry-compile prohibition and the PIP typing around it.
|
||||
- This repo does not implement Staff judgment, a PDP, observation, or
|
||||
actuation, because it implements nothing yet — restraint by vacancy,
|
||||
which is the correct vacancy.
|
||||
|
||||
## What must not be done here
|
||||
|
||||
- Do not become a second decision point, including by compiling a level
|
||||
into a registry or by letting a consumer branch on a fetched level.
|
||||
- Do not author ladder criteria that belong to `gate-house` or `ops-warden`.
|
||||
- Do not take the gap-record schema away from Taxonomy.
|
||||
- Do not publish a PEP stance map from this repository.
|
||||
- Do not absorb work structure into the gap register.
|
||||
- Do not treat observation-in-production or automatic containment as
|
||||
available, and do not take those gaps as ours to close.
|
||||
- Do not emit synchronously to `audit-core` inside a state-change
|
||||
transaction if a level or gap fact is load-bearing.
|
||||
- Do not rank blocked-clean below conforming in any scorer.
|
||||
|
||||
## Necessities for the current implementation
|
||||
|
||||
Ordered by what this repository can close without pretending to own a PDP:
|
||||
|
||||
1. **Machine-readable declaration.** `layer.yaml` in the kings-guard
|
||||
no-contact shape adapted for Engine/PIP: empty `tooling_contacts`, State
|
||||
Hub listed under `non_tooling_clients` once used, no `pep_stance` path,
|
||||
catalog owns transcribed from §4. `INTENT.md` frontmatter already
|
||||
declares the layer. Keep the file and the frontmatter equal.
|
||||
2. **Repository baseline.** Layout, stack, test harness, persistence
|
||||
choice. There is no implementation to "update"; there is one to start.
|
||||
3. **Deterministic assessment core.** Models, evidence, computation,
|
||||
explainability, history, expiry. Same inputs, same level, with a test
|
||||
that a subject loses a level when evidence expires.
|
||||
4. **Gap register.** Schema fields from statute §17 plus `state` and
|
||||
owner-status; seed from the §13 snapshot; four conformance states;
|
||||
scoring rule as a test. Then notice `gate-house` / `net-kingdom`.
|
||||
5. **Stance-map inventory and capability readiness.** Take §13.1; expose
|
||||
pending / declared-gap / surface-exists as queries.
|
||||
6. **Claim contract, guardrail tests, evidence emission.** Levels as
|
||||
claims; no registry compile; local outbox.
|
||||
7. **First two ladders and the gate-house review path.** ASM content
|
||||
remains `gate-house`'s. A second ladder from a different owner is the
|
||||
minimum evidence this is a model. Refresh `SCOPE.md` against evidenced
|
||||
artifacts when those land.
|
||||
|
||||
## Disposition
|
||||
|
||||
**Accepted** as `MAT-WP-0001`.
|
||||
|
||||
The work belongs here because statute §4, §9.5, §13, and §13.1 already
|
||||
name this repository as the owner of the missing surfaces. Engine
|
||||
implementation is in-scope. PDP behaviour, doctrine authorship, observation,
|
||||
and actuation are routed outward.
|
||||
222
workplans/MAT-WP-0001-netkingdom-security-layer-engine.md
Normal file
222
workplans/MAT-WP-0001-netkingdom-security-layer-engine.md
Normal file
|
|
@ -0,0 +1,222 @@
|
|||
---
|
||||
id: MAT-WP-0001
|
||||
type: workplan
|
||||
title: "Stand up maturity-engine on security-layer-model v0.7"
|
||||
domain: infotech
|
||||
repo: maturity-engine
|
||||
status: ready
|
||||
owner: grok
|
||||
topic_slug: netkingdom-security-layer-alignment
|
||||
created: "2026-08-29"
|
||||
updated: "2026-08-29"
|
||||
---
|
||||
|
||||
# MAT-WP-0001 - Stand up maturity-engine on security-layer-model v0.7
|
||||
|
||||
## Goal
|
||||
|
||||
Make this repository a conforming Engine/PIP under NetKingdom Security
|
||||
Layer Model v0.7: declare the layer in a machine-readable form, stand up
|
||||
the deterministic assessment surface, take the gap register and PEP
|
||||
stance-map inventory off the statute, encode the scoring and guardrail
|
||||
rules as tests, and give `gate-house` an engine to review through.
|
||||
|
||||
Source review: `history/260829-demand-netkingdom-security-layer-alignment.md`.
|
||||
Statute: `net-kingdom/canon/standards/security-layer-model_v0.7.md`.
|
||||
Companion: `net-kingdom/SECURITY-COMPANION.md` v0.2.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not render or cache an authorization decision. We are a PIP.
|
||||
- Do not compile a maturity level into registry content.
|
||||
- Do not let a consumer branch on a fetched level; the claim contract is
|
||||
the only sanctioned path into `access-engine`.
|
||||
- Do not author ladder criteria. ASM-0…ASM-6 stays `gate-house`'s.
|
||||
- Do not author the gap-record schema; Taxonomy owns it (statute §17).
|
||||
- Do not publish a PEP stance map from this repository.
|
||||
- Do not absorb work structure (owners, estimates, due dates as task
|
||||
fields) into the gap register.
|
||||
- Do not treat observation-in-production or automatic containment as
|
||||
available, and do not take those zeros as ours to close.
|
||||
- Do not rank blocked-clean below conforming.
|
||||
- `approval-engine` remains the opposite object: closed, binary, replay-proof.
|
||||
- Persistence is this PIP's own store, not Lifecycle over `OpenBao` or
|
||||
`key-cape`.
|
||||
|
||||
## T01 - Machine-readable layer declaration
|
||||
|
||||
```task
|
||||
id: MAT-WP-0001-T01
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Add `layer.yaml` in the kings-guard no-contact shape, adapted for Engine/PIP,
|
||||
pointing at security-layer-model v0.7:
|
||||
|
||||
- `layer: engine`
|
||||
- `role: pip`
|
||||
- `tooling_contacts: []`
|
||||
- `non_tooling_clients` lists the State Hub progress/work-record client
|
||||
once it is used
|
||||
- no `pep_stance` path
|
||||
- `catalog_entry` transcribed from statute §4: graded progression, gap
|
||||
register, capability readiness
|
||||
|
||||
`INTENT.md` frontmatter already declares `layer: Engine`, `role: PIP`.
|
||||
Keep the file and the frontmatter equal. A conformance script is optional
|
||||
in this task; the declaration file is the §11 surface.
|
||||
|
||||
**Done when:** `layer.yaml` is committed, agrees with `INTENT.md`, and a
|
||||
reviewer can see there are no Tooling contacts and no PEP claim.
|
||||
|
||||
## T02 - Repository baseline
|
||||
|
||||
```task
|
||||
id: MAT-WP-0001-T02
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
There is no implementation to update. Choose and record:
|
||||
|
||||
- language, test harness, and local commands;
|
||||
- module boundaries for models, evidence, computation, register, claims,
|
||||
and emission;
|
||||
- the persistence store for this PIP (our own, transactional enough for a
|
||||
local outbox).
|
||||
|
||||
Add `AGENTS.md` (or equivalent) so later sessions can verify changes.
|
||||
Do not pick catalogued Tooling as the store. List any uncatalogued client
|
||||
in `layer.yaml` when it is introduced.
|
||||
|
||||
**Done when:** a contributor can run a documented test command against a
|
||||
scaffold, and SCOPE's "no runtime" bullet is no longer the whole story.
|
||||
|
||||
## T03 - Deterministic assessment core
|
||||
|
||||
```task
|
||||
id: MAT-WP-0001-T03
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Implement the modeled concept:
|
||||
|
||||
- named, versioned ladders with ordered levels and criteria;
|
||||
- evidence submission with validity windows;
|
||||
- deterministic level computation, explainable by construction (criteria
|
||||
met, evidence used, next level required);
|
||||
- progression history;
|
||||
- demotion when evidence expires.
|
||||
|
||||
Same criteria and same evidence MUST return the same level. A subject MUST
|
||||
be able to lose a level. Criteria that cannot be evaluated by rule are
|
||||
rejected, not interpreted.
|
||||
|
||||
**Done when:** tests demonstrate determinism, explainability, and expiry
|
||||
demotion from recorded inputs, with no human in the compute path.
|
||||
|
||||
## T04 - Gap register
|
||||
|
||||
```task
|
||||
id: MAT-WP-0001-T04
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Take statute §13's snapshot into this engine:
|
||||
|
||||
- record fields: `capability`, `intended_owner`, `blocked_on`, `review`,
|
||||
plus `state` and owner-status (statute §13 / §17);
|
||||
- two marks: `pending` and `declared-gap`;
|
||||
- owner-status: proposed ≠ assigned;
|
||||
- four conformance states;
|
||||
- scoring rule: blocked-clean MUST NOT rank below conforming, asserted by
|
||||
a test.
|
||||
|
||||
Seed from the current §13 table. Do not turn register entries into work
|
||||
items. Notify `gate-house` / `net-kingdom` so the statute table can become
|
||||
a pointer.
|
||||
|
||||
**Done when:** the §13 rows are queryable here, the two surviving columns
|
||||
are present, the scoring test fails if blocked-clean ranks below
|
||||
conforming, and notice has been sent.
|
||||
|
||||
## T05 - Stance-map inventory and capability readiness
|
||||
|
||||
```task
|
||||
id: MAT-WP-0001-T05
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Take statute §13.1's inventory: every PEP-shaped consumer's published
|
||||
unreachable-engine stance map, including currently unpublished ones
|
||||
(`ops-mason`). Do not author maps.
|
||||
|
||||
Expose capability readiness as a query: pending (no route, no contact),
|
||||
declared-gap (route through a §5.3 contact), or surface exists. This is
|
||||
how `kings-guard`'s pending containment claim becomes a fact rather than
|
||||
a footnote — containment itself stays the unowned actuation surface.
|
||||
|
||||
**Done when:** stance maps are listed here, unpublished PEPs are visible
|
||||
as absences, and a readiness query returns pending / declared-gap /
|
||||
surface-exists without implying ownership of actuation.
|
||||
|
||||
## T06 - Claim contract, guardrail, evidence emission
|
||||
|
||||
```task
|
||||
id: MAT-WP-0001-T06
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
Publish the PIP claim shape `access-engine` consumes for a maturity
|
||||
level. Bind:
|
||||
|
||||
- levels arrive as request claims or versioned policy rules (statute §6.2 /
|
||||
§9.5);
|
||||
- a level MUST NOT be compiled into registry content;
|
||||
- a consumer MUST NOT branch on a fetched level.
|
||||
|
||||
Emit assessment and register mutations to `audit-core`. Queue locally in
|
||||
this engine's store. No synchronous `audit-core` dependency inside the
|
||||
state-change transaction. Classify load-bearing vs attributive once a
|
||||
claim is actually consumed; rare load-bearing classes need reconciliation
|
||||
or a heartbeat, not a rate.
|
||||
|
||||
**Done when:** the claim contract is in-repo, guardrail tests reject a
|
||||
registry compile and a consumer branch, and emission is queued locally
|
||||
with the §9.6 bound stated next to the trail.
|
||||
|
||||
## T07 - First ladders, review path, SCOPE closeout
|
||||
|
||||
```task
|
||||
id: MAT-WP-0001-T07
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
Register at least two ladders owned by different repositories. The first
|
||||
is ASM-0…ASM-6; content remains `gate-house`'s. The second proves this is
|
||||
a model rather than a preference.
|
||||
|
||||
Expose the surface `gate-house` uses for conformance review — compute and
|
||||
remember, not judge.
|
||||
|
||||
After T01–T06, refresh `SCOPE.md` Current State and Gap to Intent so they
|
||||
describe evidenced artifacts rather than the 2026-08-29 seed deficit.
|
||||
Keep Intent aspirational. Do not mark this workplan finished while T03
|
||||
and T04 are open.
|
||||
|
||||
**Done when:** two ladders are registered, `gate-house` can review through
|
||||
this engine rather than by reading files, SCOPE matches the files on
|
||||
disk, and this workplan can move to `finished` without leaving silent
|
||||
follow-on work that still belongs to the seed-to-engine gap.
|
||||
|
||||
## Sequencing
|
||||
|
||||
T01 can proceed immediately. T02 unblocks T03–T06. T03 and T04 are the
|
||||
load-bearing pair; T05 may proceed once the store from T02 exists. T06
|
||||
needs T03. T07 is last.
|
||||
Loading…
Add table
Add a link
Reference in a new issue