diff --git a/GOAL.md b/GOAL.md index c13bbc6..38b0be2 100644 --- a/GOAL.md +++ b/GOAL.md @@ -17,21 +17,26 @@ expires on its own. ## Invariants -- **`flex-auth` remains the only policy decision point.** zone-engine is - authority over zone **identity and membership**; the **effect** of a zone on - any decision flex-auth renders is expressed in a flex-auth policy package. +- **`access-engine` remains the only policy decision point.** It is the ruled + name for the repository currently called `flex-auth`. zone-engine is the + Engine-layer **PIP** for zone **identity and membership**; the **effect** of + a zone on any decision `access-engine` renders is expressed in an + `access-engine` policy package or as a claim on the request (security layer + model v0.7 §6, §18). The first draft of this invariant said "nothing this repo builds sits synchronously in a decision path". flex-auth rejected that on review: it is a *latency* guarantee, not an authority one. Compiled data that determines an outcome is still deciding — it just decided earlier. Under the old wording zone-engine could compile `enforced: false` for a lane, flip `warden sign` - from deny to allow with no flex-auth policy change, and be literally - compliant. Membership is ours; stance is theirs. -- **Compiled, not queried.** Membership reaches flex-auth by compilation into - the registry it already loads. This is a *consequence* of the invariant - above, not the invariant itself — flex-auth is `service_class: - latency-critical` and loads its registry once at process start. + from deny to allow with no policy-package change, and be literally + compliant. Membership is ours; stance is theirs; the decision point is + neither. +- **Compiled, not queried.** Membership reaches `access-engine` by compilation + into the registry it already loads, as a PIP fact, never as stance. This is + a *consequence* of the invariant above, not the invariant itself — + `access-engine` is `service_class: latency-critical` and loads its registry + once at process start. - **A zone that can be quietly widened is not a boundary.** Every change of stance is observable, and every exception has an enforced expiry. - **Accuracy, not altitude** (`tenancy-posture_v0.1` §6). A repo declaring a @@ -64,15 +69,23 @@ runtime exists with an owner or the decision that none is needed is recorded. It does not reopen the no-runtime decision; it makes the retained artifacts truthful enough for an explicit archive-or-maintain decision. +`ZONE-WP-0003` is the owner-driven revision that follows from security layer +model v0.7 being accepted. It declares the Engine/PIP layer, records the +already-completed layer cut, and evolves the reference surface so zone facts +can be consumed as claims. It does not add a live API, a decision surface, or +a PEP. + ## Retirement decision — 2026-08-23 Retain the repository as an offline reference-conformance repository while the -canonical v0.1 standard remains `proposed`. The maintainer is zone-engine; the -maintenance surface is limited to canon lineage, conformance fixtures, and -concrete owner-driven revisions. There is no service or routine delivery -backlog. +canonical `security-zones_v0.1` standard remains `proposed`. The maintainer is +zone-engine; the maintenance surface is limited to canon lineage, conformance +fixtures, and concrete owner-driven revisions. There is no service or routine +delivery backlog. The 2026-08-29 layer declaration is one such revision: the +security layer model is **accepted**; the zone standard is still **proposed**; +the catalogued form stays offline. -Reassess archival when net-kingdom accepts or supersedes v0.1, when the fixtures -are durably adopted by canon/control owners, or when no adopting control needs -the reference. An actual Forgejo archive or rename remains attended operator -work. +Reassess archival when net-kingdom accepts or supersedes `security-zones_v0.1`, +when the fixtures are durably adopted by canon/control owners, or when no +adopting control needs the reference. An actual Forgejo archive or rename +remains attended operator work. diff --git a/INTENT.md b/INTENT.md index d01df50..1c6e2f4 100644 --- a/INTENT.md +++ b/INTENT.md @@ -1,37 +1,74 @@ -# INTENT +--- +layer: Engine +role: PIP +standard: netkingdom-security-layer-model +standard_version: "0.7" +companion: net-kingdom/SECURITY-COMPANION.md +--- -> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed -> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines → -> Staff**, layered by determinism and by the kind of artifact each layer produces. -> Findings and the argument behind them: -> `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`. -> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed), -> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001. -> -> The layer rule that binds every repository: **Staff never touches tooling -> directly. It acts only through engine APIs.** -> -> **This repository is Engine — currently retained as offline reference conformance.** No change to the 2026-08-23 disposition. Note that §5 of this file — *"flex-auth is the policy decision point. It stays the only one."* — is the precedent the whole review turned on, and it now generalizes: gate-house is Staff and is not a second decision point either. The falsifier in §7 ("it becomes a second decision point… it would arrive as a small convenience") is adopted estate-wide. References to flex-auth by name will need updating when the rename to access-engine lands. -> -> *This note records what should change. The body below is not yet adapted.* +# INTENT > Why `zone-engine` exists and where it is going. > What is true today is `SCOPE.md`. Checkable gates and the retirement > condition are `GOAL.md`. This file is the argument, not the checklist. +> **Layer: Engine. Role: PIP.** This is the declaration required by NetKingdom +> Security Layer Model v0.7 §11 and working companion v0.2. It is this +> repository's own voice. A catalog row, a review note, or the 2026-08-28 +> gate-house insert that used to sit here is not a declaration. +> +> The statute is +> `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted +> 2026-08-29). The operative form is `net-kingdom/SECURITY-COMPANION.md` v0.2. +> On disagreement the statute governs, and a disagreement is a finding for +> `gate-house`. +> +> We produce a deterministic result for one modeled concept: zone identity and +> membership. Same authoritative inputs, same result. That is the Engine test. +> The PIP role means those facts reach a decision as **claims**, not as a +> verdict. We do not render, cache, or compile an authorization decision. +> +> The §4 catalog records the 2026-08-23 disposition rather than changing it: +> the current PIP surface is **offline reference conformance**, not a live API. +> Determinism does not require a network. A live Engine API, a decision +> surface, or stance compiled into membership would each be a layer change, +> and a layer change needs the six artifacts in statute §10, including a +> permission freeze. The 2026-08-23 cut already happened; it does not reopen +> by practice. +> +> **`access-engine` is the only PDP.** It is the ruled name for the repository +> currently called `flex-auth`. This file's original §5 — *"flex-auth is the +> policy decision point. It stays the only one."* — is the ruling the layer +> model generalizes as statute §6. The §7 falsifier — a second decision point +> arriving as a small convenience — is estate doctrine. Zone stance enters a +> decision as a claim on the request or a rule in a versioned policy package, +> never as compiled registry content (statute §18). +> +> We are not PEP-shaped: this repository causes no protected side effect and +> publishes no unreachable-engine stance map. We hold no Tooling-layer client. +> Staff never touches Tooling directly; we are not Staff, and we still do not +> hold a Tooling client, because a PIP that reaches into OpenBao would be +> deciding with someone else's state. + --- -## Current disposition — 2026-08-23 +## Current disposition — 2026-08-23, confirmed 2026-08-29 The argument below is retained as design history. Its desired sentence is now -sayable: the standard is in net-kingdom canon, ops-warden and flex-auth have -adopted it, the repo-wide switch is retired, and exception expiry is enforced -at each owning decision or enforcement point. +sayable: the zone standard is in net-kingdom canon, ops-warden and flex-auth +have adopted it, the repo-wide switch is retired, and exception expiry is +enforced at each owning decision or enforcement point. -The runtime hypothesis was falsified. zone-engine is retained only as an -offline reference-conformance repository while canon v0.1 remains proposed; it -is not an engine, PDP, exception service, or consumer policy owner. Current -capability is `SCOPE.md`, and the retain/archive triggers are in `GOAL.md`. +The runtime hypothesis was falsified. That was a layer change in practice +(statute §10 cites this case). zone-engine is retained as an Engine/PIP whose +surface is offline reference conformance while `security-zones_v0.1` remains +proposed. It is not a PDP, not a PEP, not an exception service, and not a +consumer policy owner. Current capability is `SCOPE.md`. Retain and archive +triggers are in `GOAL.md`. + +The security-layer-model being accepted does not reverse that cut. It names +the cut: we are the PIP for zone identity and membership, in the form already +shipped. ## 1. The sentence this repo exists to make sayable @@ -39,10 +76,10 @@ capability is `SCOPE.md`, and the retain/archive triggers are in `GOAL.md`. > band until Friday** — and all three of those are written down, reviewable, and > expire on their own."* -At inception NetKingdom could not say that. It could say how exposed a workload was -(environment posture), how ready it is (`M0`–`M3`), and what state the +At inception NetKingdom could not say that. It could say how exposed a workload +was (environment posture), how ready it is (`M0`–`M3`), and what state the organization is in (`organization_posture`). Every one of those **describes**. -None of them **decides**. So every enforcement control in the estate has been a +None of them **decides**. So every enforcement control in the estate was a boolean over a whole repo. ## 2. Where that bit @@ -52,7 +89,7 @@ the gate verified clean. It was deliberately not switched on until the zone model replaced its global scope. `policy.enabled` is one boolean over the entire repo. With `fail_closed: true` -it makes flex-auth a hard dependency of *every* `warden sign` — including the +it makes the PDP a hard dependency of *every* `warden sign` — including the SSH certificates the ops-bridge tunnels depend on, one of which carries the policy call itself. Turning it on would have been correct for a settled production lane and wrong for an estate in the middle of decommissioning one @@ -93,44 +130,54 @@ it decides something, so the model must carry: - **Identity and membership** — an authoritative workload binding and its responsible party's declared zone. Lanes, actors, paths and repositories are - inputs or caller context, never substitute policy subjects. + inputs or caller context, never substitute policy subjects. **This is the PIP + fact this repository owns.** - **Admission** — a mechanical reconciliation of that declaration against the zone floor and the workload posture. Missing identity, membership or evidence - remains `unknown`; it is never inferred into a permissive zone. -- **Stance per control** — enforced, advisory, or exempt. + remains `unknown`; it is never inferred into a permissive zone. Same + authoritative inputs, same result. +- **Stance per control** — enforced, advisory, or exempt. **Not ours.** The + effect of a zone on a decision belongs in a versioned `access-engine` policy + package, or as a claim on the request (statute §18). - **Failure mode** — what happens when the control cannot run. This is where - the bite is; `fail_closed` is what turns a dead tunnel into an outage. + the bite is; `fail_closed` is what turns a dead tunnel into an outage. **The + PEP owner's**, declared ahead of time per statute §9.3. - **Exceptions that expire without anyone remembering them.** -The last was the runtime hypothesis. A standing classification needs no engine -— canon plus a declaration file covers it, which is exactly how tenancy posture -works. The implementation proved that exception state can remain with the -control owner when `not_after` is evaluated where the effect occurs. That gives -it an owner, audit trail, and enforced deadline without a central service. +The last was the runtime hypothesis. A standing classification needs no live +engine — canon plus a declaration file covers it, which is exactly how tenancy +posture works. The implementation proved that exception state can remain with +the control owner when `not_after` is evaluated where the effect occurs. That +gives it an owner, audit trail, and enforced deadline without a central service. ## 5. The line this repo must not cross -`flex-auth` is the policy decision point. It stays the only one. +`access-engine` (currently `flex-auth`) is the policy decision point. It stays +the only one. zone-engine is authority over zone **identity and membership**. The **effect** -of a zone on a decision flex-auth renders belongs in a flex-auth policy package, -because flex-auth's decision envelope stamps `matched_policy_version` and -`policy_package` — and registry content appears nowhere in that provenance. Put -stance in the registry and two decisions with the same policy version and the -same request can differ, with nothing in the audit trail explaining why. +of a zone on a decision `access-engine` renders belongs in an `access-engine` +policy package, because the decision envelope stamps `matched_policy_version` +and `policy_package` — and registry content appears nowhere in that provenance. +Put stance in the registry and two decisions with the same policy version and +the same request can differ, with nothing in the audit trail explaining why. That boundary was drawn by flex-auth on review, against a first draft of ours that got it wrong in an instructive way: the original invariant forbade sitting *synchronously* in a decision path, which is a latency guarantee wearing an authority guarantee's clothes. Compiled data that determines an outcome is still -deciding; it just decided earlier. +deciding; it just decided earlier. Statute §6.1 is that sentence, generalized. **Held to, in one line: membership is ours, stance is theirs, and the decision point is neither.** +A new engine is a PIP unless the statute is amended. We are already that PIP. +We will not become a second PDP by growing a convenient live lookup, a cached +verdict, or a profile that changes a live effect. + ## 6. What success looks like from outside -These conditions are now met for the adopted v0.1 path: +These conditions are met for the adopted v0.1 path: Someone who has never read this repo should be able to: @@ -145,6 +192,11 @@ Someone who has never read this repo should be able to: If a reader has to come here to understand their own posture, the model has failed at being a standard and has succeeded only at being a service. +Under the layer model, the same reader should also be able to say: zone +*facts* come from this PIP; zone *effect* lives in `access-engine` policy; +unreachable-engine *behaviour* is the PEP's declared stance. Three owners, +one reconstructable decision. + ## 7. What would make this repo wrong Stated up front, because a repo created on a recommendation should say what @@ -152,8 +204,9 @@ would falsify it: - **The exception lifecycle turns out not to need a runtime.** This falsifier triggered. Reviewed owner records plus decision-time expiry are sufficient. - The honest outcome is canon plus offline conformance tooling, not an engine. - Retention is bounded to the proposed-standard reference need in `GOAL.md`. + The honest outcome is canon plus offline conformance tooling, not a live + engine. Retention is bounded to the proposed-standard reference need in + `GOAL.md`. - **The zones do not partition the real estate.** If the model needs a residue of special cases to cover today's 27 routing lanes and actor inventory, it is describing an aspiration, not a structure. @@ -161,16 +214,27 @@ would falsify it: reading is the minimum evidence of a model rather than a preference. - **It becomes a second decision point.** The failure would not announce itself; it would arrive as a small convenience — a stance compiled into membership - "just for now". + "just for now", a live lookup "just for this consumer", a profile change that + alters a live effect with no policy-package revision. Statute §6 is this + falsifier, estate-wide. ## 8. What this repo deliberately will not become -Not a PDP. Not network segmentation — "zone" is overloaded and the routing sense -is someone else's word. Not a placement model: reefs answer *where a thing runs* -and are `repo-manager`'s, and the fact that `reef-railiance` caps availability -for everything bound to it is a canon composition problem (`NK-WP-0027`), not -ours. Not an owner of anyone's controls — the controls stay with the repos that -enforce them; this model only says where they bite. +Not a PDP. Not a PEP. Not network segmentation — "zone" is overloaded and the +routing sense is someone else's word. Not a placement model: reefs answer +*where a thing runs* and are Railiance's, and the fact that `reef-railiance` +caps availability for everything bound to it is a canon composition problem +(statute §20.3, originally `NK-WP-0027`), not ours. Not an owner of anyone's +controls — the controls stay with the repos that enforce them; this model only +says where they bite. + +Not a live Engine API unless a later layer-change decision carries the six +§10 artifacts and obtains assent from the repositories whose boundaries move. +The catalogued offline form is the current Engine, not a temporary embarrassment. + +Not an inventor of the estate request-claim schema. Statute §17 assigns that +artifact to Taxonomy. Until it exists, this PIP's resolver output is +reference-shaped membership, not a competing claim dialect. ## 9. Direction @@ -185,3 +249,8 @@ and the cheaper answer is a legitimate result, not a disappointment. That direction is delivered. `ZONE-WP-0002` hardened the offline contracts and made canon lineage, owner provenance, revision/delta evidence, and exception fixtures executable without reopening the runtime decision. + +What remains is to live inside the layer the estate has now named: declare the +PIP in a machine-readable form, keep the permission freeze, and evolve the +reference surface so zone facts can be consumed as claims when Taxonomy +publishes the schema — without growing a second decision point to get there. diff --git a/SCOPE.md b/SCOPE.md index cf64fc9..1415415 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -8,24 +8,56 @@ ## One-liner -`zone-engine` is the retained reference-conformance repository for NetKingdom -security-zone membership, admission, owner-provenanced control profiles, and -time-boxed exception semantics. It does **not** run an engine or make policy -decisions. +`zone-engine` is the Engine-layer **PIP** for NetKingdom zone identity and +membership, retained as an offline reference-conformance repository. It does +**not** run a live engine, render a policy decision, or cause a protected side +effect. + +## Layer + +Declared in `INTENT.md` frontmatter, in this repository's own voice: + +| Key | Value | +| --- | --- | +| Layer | Engine | +| Role | PIP | +| Statute | `security-layer-model_v0.7` (accepted 2026-08-29) | +| Companion | `net-kingdom/SECURITY-COMPANION.md` v0.2 | +| Catalogued form | offline reference conformance (2026-08-23 disposition) | +| PEP-shaped | no | +| Tooling contacts | none | +| Conformance | conforming for Tooling contact; the live Engine API is not a missing capability this repository currently owes | + +The machine-readable `layer.yaml` form and a conformance check that fails a +new Tooling client or a new decision surface are not yet evidenced here. +Until they are, the declaration is the `INTENT.md` frontmatter and the prose +in that file. + +`access-engine` (currently `flex-auth`) is the only PDP. Zone stance and +failure mode remain owner policy and PEP configuration. This repository +projects only explicit versioned owner data and never changes a live effect. ## Lifecycle `ZONE-WP-0001` delivered and proved the model. `ZONE-WP-0002` hardened the retained reference boundary. Both are finished with `DoD-Ok`; no runtime is -needed and there is no continuing implementation backlog. +needed. The repository is retained while `security-zones_v0.1` remains `proposed` in net-kingdom canon, with zone-engine as maintainer of fixtures and reference -tooling. Retention is not service ownership. A future canon lifecycle change, -an owner-requested conformance revision, or evidence that an adopting control -cannot enforce the contract at its existing point are the only normal change -triggers. Archival remains an attended action once the reference artifacts are -durably handed off or no longer needed. +tooling. Retention is not service ownership. Acceptance of the security layer +model does not reopen the no-runtime decision; it names the retained form as +the Engine/PIP this repository already is. + +Normal change triggers remain: a canon lifecycle or content change, an +owner-requested conformance revision, or evidence that an adopting control +cannot enforce the contract at its existing point. The layer declaration and +the PIP claim-mapping work that follow from v0.7 are owner-driven revisions +of that kind. Archival remains an attended action once the reference +artifacts are durably handed off or no longer needed. + +A live Engine API, a decision surface, or stance compiled into membership +would be a layer change and is out of present scope. ## Capability actually present @@ -59,6 +91,10 @@ ambiguous join, read a live clock, or publish a consumer registry. Its profile fixture records owner-approved v0.1 behavior; only the referenced owner policy and PEP configuration can change a live effect. +The resolver output is a reference membership/admission record. It is not yet +a statute §17 request-claim. Taxonomy owns that schema and has not published +it. This repository must not ship a competing dialect. + ## Authority boundary | Concern | Authority | This repository's role | @@ -67,13 +103,17 @@ and PEP configuration can change a live effect. | Managed workload tuple and applicability | Repo Manager / owning catalog | Consumes the explicit projection | | Zone ids and admission standard | zone-engine model, published by net-kingdom | Maintains conformance fixtures and lineage | | Canon publication and lifecycle | net-kingdom | Detects change; never promotes by inference | -| Control stance | Owner of the control | Projects only explicit versioned owner data | +| Layer model and engine roles | gate-house / net-kingdom canon | Declares Engine/PIP; does not author the statute | +| Request-claim schema | Taxonomy (statute §17, unassigned) | Will consume, not invent | +| Control stance | Owner of the control; effect in `access-engine` policy | Projects only explicit versioned owner data | | Failure behavior | Owner of the PEP | Records provenance and semantics only | -| Authorization effect | Existing PDP or control owner | Makes no decision | +| Authorization effect | `access-engine` (currently `flex-auth`) | Makes no decision; supplies PIP facts | | Exception grant and expiry | Designated control authority and enforcement point | Checks reusable fixtures offline | +| Reef placement vs zone floor | Railiance / canon composition (statute §20.3) | Keeps the axes separate; does not compose them | The invariant remains: **membership is ours; stance is theirs; the decision -point is neither.** `flex-auth` remains the only PDP for decisions it renders. +point is neither.** `access-engine` remains the only PDP for decisions it +renders. ## Deliberately absent @@ -81,12 +121,15 @@ There is no: - API, daemon, database, controller, scheduler, watch loop, or reload path; - synchronous lookup in an authorization or enforcement path; +- authorization decision surface, cached verdict, or compiled stance; +- PEP, unreachable-engine stance map, or protected side effect; +- Tooling-layer client (OpenBao, key-cape, or a direct datastore); - central exception store, grant workflow, clock, or expiry evaluator; - live policy evaluation or implementation of another repository's control; - fleet discovery, reference repair, registry publication, or workload migration; - network segmentation, reef placement, tenancy, identity, or secrets service; - or +- estate request-claim schema, or authority to publish one; or - authority to publish canon or select a consumer's stance and failure mode. Exception expiry remains enforced at decision or enforcement time by each @@ -99,16 +142,24 @@ decision point. - Checking direct declarations or explicit Repo Manager projections offline. - Verifying a versioned owner profile is total and fully attributed. - Testing an owner exception implementation against the lifecycle boundaries. -- Reviewing a net-kingdom canon lifecycle/content change. +- Reviewing a net-kingdom canon lifecycle/content change, including the + security-layer-model. +- Declaring or checking this repository's Engine/PIP conformance. - Auditing why no zone-engine runtime exists. ## Not relevant when - Determining the published rule: read net-kingdom canon. -- Asking whether a request is allowed: use `flex-auth` or the owning control. +- Asking whether a request is allowed: use `access-engine` or the owning + control. - Discovering or repairing managed workloads: use Repo Manager and the owning catalog. - Granting, applying, or expiring a live exception: use the control owner's versioned policy or PEP configuration. - Placing a workload, routing a network, managing identity/tenancy, or handling secrets. +- Publishing an unreachable-engine stance, containing a workload, or observing + production: those are PEP, actuation, and `kings-guard`, and the last two + are held at zero by the statute. +- Mapping Railiance `reef-*` onto security zones: statute §20.3 leaves that + composition unwritten; guessing it here is out of scope. diff --git a/history/2026-08-29-security-layer-model-scope-against-intent.md b/history/2026-08-29-security-layer-model-scope-against-intent.md new file mode 100644 index 0000000..db11306 --- /dev/null +++ b/history/2026-08-29-security-layer-model-scope-against-intent.md @@ -0,0 +1,221 @@ +--- +id: ZONE-REVIEW-2026-08-29-001 +type: review +title: "Scope against intent under NetKingdom security layer model v0.7" +status: accepted +reviewed: "2026-08-29" +reviewer: grok +source: operator +consumer: zone-engine maintainers, gate-house, access-engine, ops-warden +resulting_workplan: ZONE-WP-0003 +standards: + - net-kingdom/canon/standards/security-layer-model_v0.7.md + - net-kingdom/SECURITY-COMPANION.md + - net-kingdom/canon/standards/security-zones_v0.1.md +--- + +# Review: scope against intent under security layer model v0.7 + +## 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 consuming control owners need to tell, without reconstructing +context from the 2026-08-28 gate-house insert: + +- which layer and engine role this repository occupies, in its own voice; +- that the 2026-08-23 offline disposition is the catalogued PIP form, not a + temporary embarrassment; +- that `access-engine` (currently `flex-auth`) remains the only PDP; +- which v0.7 obligations this repository already meets, which it still owes, + and which it must refuse. + +## Purpose fit + +**Strong fit.** Statute §4 already catalogs `zone-engine` as Engine / PIP for +zone identity and membership, "offline reference conformance per its +2026-08-23 disposition". Statute §6 generalizes this repository's original +INTENT §5. Statute §10 writes the layer-change procedure from this +repository's runtime-falsified case. Statute §18 restates the membership / +stance split this repository already shipped. + +`ZONE-IN-0001` asked for a layer declaration in this repository's own voice. +Companion §2 requires `layer:` and `role:` in `INTENT.md` frontmatter plus +prose. That declaration is now written. Remaining work is to make the +declaration mechanically checkable and to evolve the reference surface +without reversing the no-runtime decision. + +## Evidence reviewed + +- `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted; §2–§6, + §10, §11, §14, §18, §20.3) +- `net-kingdom/SECURITY-COMPANION.md` v0.2 (operative form; §1–§3, §8) +- `net-kingdom/canon/standards/security-zones_v0.1.md` (still `proposed`) +- `INTENT.md` and `SCOPE.md` before and after this review +- `GOAL.md`, `history/2026-08-23-retain-reference-decision.md`, + `history/2026-08-23-scope-against-intent.md` +- `docs/canon-lineage.yaml`, `tools/resolve_zones.py`, + `profiles/netkingdom-build-v0.1.yaml`, `Makefile` +- `intakes/intakes.md` `ZONE-IN-0001` +- Reference declarations: `ops-warden/layer.yaml`, `kings-guard/layer.yaml` +- Prior work: `ZONE-WP-0001` and `ZONE-WP-0002`, both `finished` / `DoD-Ok` + +MCP tools for the State Hub were not exposed in this session. The REST +surface at `http://127.0.0.1:8000` answered as primary (`railiance01`). + +## What the standard requires of this repository + +Statute §11: an estate-authored repository declares its layer in its own +`INTENT.md`, in a machine-readable form. A catalog row or a review note about +us is not a declaration. We **are** in §4, proposed layer Engine, role PIP. + +Companion §2: frontmatter `layer:` plus `role:` for engines, and prose in our +own voice. + +Statute §3.3 / §4: we own zone identity and membership as a PIP. A new engine +is a PIP unless the statute is amended. Outage of a PIP is input degradation +at `access-engine` (§9.3), not a Staff fallback. + +Statute §6 / §18: `access-engine` is the only PDP. Zone stance enters a +decision as a claim or a versioned policy rule, never as compiled registry +content. Compiled data that determines an outcome is still deciding. + +Statute §10: the 2026-08-23 runtime-falsified cut is a layer change and must +carry six artifacts. The procedure was written from this case after the fact; +the artifacts are incomplete. + +Statute §5 / §11: no undeclared Tooling contact. We are Engine, not Staff, so +the three Staff shapes are not our lane; we still must not hold a Tooling +client, and we must record non-Tooling clients so the check is total. + +Companion §5 / statute §6.4: PEP obligations attach to runtimes that cause a +protected side effect. This repository does not. No stance map is owed. + +Statute §17: the request-claim schema is Taxonomy's and is unassigned. Until +it exists, every engine that invents its own claim shape is the drift §17 +exists to prevent. + +Statute §20.3: reef-versus-zone composition is unwritten. This repository +already recorded that as a canon composition problem and must not guess a +mapping. + +Statute §14: as of 2026-08-29 this repository is one of the nine §4 +repositories that have not declared in their own voice. `ZONE-IN-0001` is +that request. + +## Intent-to-scope map (after the 2026-08-29 rewrite) + +| Intent claim | Present scope | Implementation | +| --- | --- | --- | +| Engine / PIP for zone identity and membership | Declared in `INTENT.md` frontmatter and prose | No `layer.yaml`; no conformance check | +| Offline reference is the catalogued PIP form | SCOPE names it; retain decision unchanged | Resolver, lineage, fixtures, 29 tests — shipped | +| Same inputs, same result | Offline tools are deterministic | `make check` covers resolver, exceptions, tests | +| `access-engine` is the only PDP | SCOPE / GOAL name the ruled name; fixtures still say `flex-auth` | No decision surface in this repo | +| Stance in policy package or as a claim, never registry | Profile projection is optional, versioned, owner-provenanced | Profile fixture still uses `flex-auth` as the owner identity, which is correct until the rename | +| Not PEP-shaped | SCOPE says no stance map | Nothing to publish; do not add one | +| No Tooling contact | SCOPE claims none | True of `tools/` (stdlib + PyYAML); not mechanically checked | +| Layer change already happened; freeze holds | INTENT states the freeze | §10 artifact set is incomplete | +| Exception expiry at the owning control | Offline checker, explicit instant | Shipped in `ZONE-WP-0002` | +| Consumers understand posture without reading this repo | Canon + owner declarations | Still true for the adopted v0.1 path | +| Request-claim schema | Explicitly out of scope to invent | Resolver emits membership records, not claims | +| Reef / zone composition | Out of scope to guess | Unchanged; statute §20.3 agrees | + +## Gaps that are this repository's to close + +These are the relevant remaining requirements. They are owner-driven +revisions under the 2026-08-23 retain contract, not a reopening of the +runtime. + +### 1. The declaration is prose-plus-frontmatter, not yet a check + +Companion §2 and statute §11 treat `INTENT.md` frontmatter as the declaration +surface, and they also offer `layer.yaml` plus a conformance script as the +estate working reference. `ops-warden` and `kings-guard` already ship that +shape. Without it, a new OpenBao client or a new `/authorize`-shaped helper +would land as a small convenience and nothing in `make check` would fail. + +**Necessary:** a `layer.yaml` in the kings-guard no-contact shape, with +`layer: engine`, `role: pip`, empty `tooling_contacts`, recorded non-Tooling +clients, no `pep_stance` path; plus a checker that fails undeclared Tooling +imports and any authorization decision surface. + +### 2. `ZONE-IN-0001` is still open + +The intake asked for a declaration in this repository's own voice, or a +contest. The declaration is now written and does not contest the proposed +Engine layer. The intake should close against that answer and against +`ZONE-WP-0003` for the mechanical remainder. `gate-house` should be told so +statute §14 stops counting this repository among the silent nine. + +### 3. Statute §10 artifacts for the 2026-08-23 cut are incomplete + +The layer-change procedure requires: before/after `INTENT.md`, client +inventory, gap inventory, assent list, state-migration decision, and +permission freeze. The retain decision covers state migration. The 2026-08-29 +`INTENT.md` is the after-declaration. Client inventory, gap inventory, assent +list, and an explicit freeze record are not yet written as one set. + +**Necessary:** a short retrospective note, not a new runtime. The freeze is +the checkable piece: no live API, no decision surface, no compiled stance. + +### 4. Consumer-facing naming still says only `flex-auth` + +`INTENT.md`, `SCOPE.md`, and `GOAL.md` now use `access-engine` as the ruled +name and `flex-auth` as the current repository identity. `README.md` and +older evidence still do not. Fixtures that pin the actual flex-auth +declaration must keep that identity until the governed rename lands — they +are evidence, not vocabulary. + +**Necessary:** `README.md` naming; leave fixture owner ids alone. + +### 5. PIP output is membership, not a claim + +Statute §18 says zone facts enter a decision as a claim or a policy rule. +The resolver emits a canonical membership/admission record. That is the +right fact set and the wrong envelope, and inventing the envelope here would +violate statute §17. + +**Necessary:** a short PIP claim-boundary note that maps current resolver +fields onto the facts a future claim must carry, marks the mapping as a +contribution to Taxonomy rather than a schema, and forbids a competing +dialect. Do not wait by growing a live API. + +## Gaps that are not this repository's to close + +| Gap | Owner | Why not here | +| --- | --- | --- | +| Live Engine API / daemon | — | Retain decision forbids it; catalog records the offline form; §10 freeze | +| Compiling stance into registry content | `access-engine` policy packages | Original invariant; statute §6.1 / §18 | +| Registry-snapshot digest in decision provenance | `access-engine` (self-declared in §13) | A PDP provenance gap, not a PIP one | +| Request-claim schema | Taxonomy (§17, unassigned) | Inventing it here is the defect §17 exists to prevent | +| PEP unreachable-engine stance maps | PEP-shaped consumers; §13.1 register | We cause no protected side effect | +| Reef / zone composition | `railiance-master` + net-kingdom canon (§20.3) | Placement is not posture | +| Observation in production | `kings-guard`; currently unstaffed | Statute §2 / §12; do not cite it | +| Actuation / containment | Engine concept held at zero (§9.2) | Not ours to own or to assume | +| `flex-auth` → `access-engine` repository rename | `access-engine` governed migration | Touches this repo's prose later; not a zone-engine workplan | +| `security-zones_v0.1` remaining `proposed` | net-kingdom | Lineage already pins it; do not promote by inference | +| Estate-wide reference migration | Workload and catalog owners | `ZONE-WP-0002` already excluded this | + +## Recommendation + +Keep the repository as the catalogued offline PIP. Declare, check, and freeze. +Do not grow a service to look more like the word "engine". Close `ZONE-IN-0001` +on the declaration already written. Open `ZONE-WP-0003` for the mechanical +and documentary remainder only. + +## Disposition of `ZONE-IN-0001` + +**Assent to the proposed layer, with a form clarification rather than a +contest.** Engine is correct. PIP is the role the catalog already recorded. +The 2026-08-23 offline disposition is the current surface, not a decline of +the layer. Contesting would have been appropriate if the catalog had required +a live API; it does not. + +Closed against the 2026-08-29 `INTENT.md` declaration. Mechanical remainder +is `ZONE-WP-0003`. diff --git a/intakes/intakes.md b/intakes/intakes.md index 03de015..12c946e 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -7,7 +7,9 @@ id: ZONE-IN-0001 kind: intake title: 'Declaration requested: state this repository''s layer in INTENT.md (security layer model §11)' -status: open +status: closed +outcome: absorbed +promoted_to: ZONE-WP-0003 origin: cross-repo origin_ref: net-kingdom security-layer-model_v0.4 §11 priority: low @@ -34,5 +36,15 @@ description: 'A conformance sweep on 2026-08-28 found this repository has no lay repository actually does, that is more useful to us than a label added to close a checkbox. Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.' created: '2026-08-28T21:02:13.994597Z' -updated: '2026-08-28T21:02:13.994597Z' +updated: '2026-08-29' +closed: '2026-08-29' +resolution: >- + Assent to the proposed Engine layer, with PIP as the role the v0.7 catalog + already recorded. Declaration is in INTENT.md frontmatter (layer: Engine, + role: PIP) and prose, against security-layer-model_v0.7 and companion v0.2, + in this repository's own voice. The 2026-08-23 offline reference form is the + catalogued PIP surface, not a contest of the layer. Mechanical remainder + (layer.yaml, conformance check, §10 freeze record, claim-boundary note) is + ZONE-WP-0003. Full review: + history/2026-08-29-security-layer-model-scope-against-intent.md. ``` diff --git a/workplans/ZONE-WP-0003-security-layer-model-alignment.md b/workplans/ZONE-WP-0003-security-layer-model-alignment.md new file mode 100644 index 0000000..a06ee5c --- /dev/null +++ b/workplans/ZONE-WP-0003-security-layer-model-alignment.md @@ -0,0 +1,250 @@ +--- +id: ZONE-WP-0003 +type: workplan +title: "Declare Engine/PIP and freeze the offline zone-membership surface" +domain: infotech +repo: zone-engine +status: ready +owner: zone-engine +assignee: grok +lane: yellow +topic_slug: netkingdom +planning_priority: P1 +created: "2026-08-29" +updated: "2026-08-29" +origin: "history/2026-08-29-security-layer-model-scope-against-intent.md" +context_paths: + - "GOAL.md" + - "INTENT.md" + - "SCOPE.md" + - "README.md" + - "intakes/intakes.md" + - "history/2026-08-23-retain-reference-decision.md" + - "history/2026-08-29-security-layer-model-scope-against-intent.md" +quality_dor: DoR-Ok +quality_dor_at: "2026-08-29" +quality_dor_by: grok +quality_dor_note: "Gaps are evidenced against security-layer-model v0.7, companion v0.2, and the shipped offline resolver; owners, stop conditions, and the no-runtime freeze are explicit." +--- + +# ZONE-WP-0003 — Declare Engine/PIP and freeze the offline zone-membership surface + +## Goal + +Make this repository a conforming Engine-layer PIP under NetKingdom Security +Layer Model v0.7 without reversing the 2026-08-23 no-runtime decision. Declare +the layer in a machine-readable form, close the declaration intake, record the +already-completed layer cut, and map current membership output onto the facts +a future request-claim must carry. + +Source review: `history/2026-08-29-security-layer-model-scope-against-intent.md`. +Statute: `net-kingdom/canon/standards/security-layer-model_v0.7.md`. +Companion: `net-kingdom/SECURITY-COMPANION.md` v0.2. + +`INTENT.md` already declares `layer: Engine` and `role: PIP` in this +repository's own voice. This workplan makes that declaration checkable and +closes the remaining documentary gaps. It does not add a live API. + +## Why these gaps are the relevant ones + +| Priority | Gap | Why address it here | +| --- | --- | --- | +| P0 | No `layer.yaml` or conformance check | Statute §11 is mechanical; a new Tooling client or decision surface would land as the small convenience §6 warns about | +| P0 | `ZONE-IN-0001` still open after the declaration | gate-house asked for our voice; §14 still counts us among the silent nine | +| P1 | Statute §10 artifacts for the 2026-08-23 cut are incomplete | The procedure was written from this case; the freeze is the checkable piece | +| P1 | `README.md` still names only `flex-auth` | Consumer-facing docs must use the ruled PDP name | +| P1 | Resolver output is membership, not a claim | Statute §18 wants claims; §17 forbids inventing the schema here | + +A live Engine API, a PEP stance map, compiled stance, reef/zone composition, +and the `flex-auth` repository rename are intentionally excluded. + +## Authority and dependencies + +- **gate-house / net-kingdom** own the statute and the §4 catalog. This plan + declares into that catalog; it does not edit it. +- **`access-engine` (currently `flex-auth`)** owns the PDP, policy packages, + and the governed rename. This plan uses the ruled name in prose and leaves + fixture owner identities as `flex-auth` until that rename lands. +- **Taxonomy** owns the request-claim schema (statute §17, unassigned). This + plan offers a field mapping, not a schema. +- **zone-engine** owns the declaration, the conformance check, the freeze + record, and the PIP mapping note. +- **Operator action** is not required. No archive, rename, or service + deployment is in this plan. + +## Boundaries + +- Do not add an API, daemon, database, controller, scheduler, or reload path. +- Do not expose an authorization decision surface or cache a verdict. +- Do not compile stance into membership or change a live effect from a local + profile edit. +- Do not publish a PEP stance map; this repository is not PEP-shaped. +- Do not invent the estate request-claim schema. +- Do not map `reef-*` onto security zones. +- Do not treat observation-in-production or automatic containment as available. +- Do not fold `ZONE-WP-0001` or `ZONE-WP-0002` back open. +- Leave fixture `policy_owner` / source identities as the actual repository + names they pin. + +## T01 - Machine-readable layer declaration and conformance check + +```task +id: ZONE-WP-0003-T01 +status: todo +priority: high +``` + +Add `layer.yaml` in the kings-guard no-contact shape, pointing at security +layer model v0.7: + +- `layer: engine` +- `role: pip` +- `tooling_contacts: []` +- `non_tooling_clients` lists any State Hub / work-record client, recorded + as not-catalogued +- no `pep_stance` path +- catalog note: §4 Engine / PIP; offline reference conformance per the + 2026-08-23 disposition + +Add `tools/check_layer_conformance.py` and a unit test. The check must fail +if: + +- `layer.yaml` is missing, unparseable, or disagrees with `INTENT.md` + frontmatter; +- a Tooling-layer client import appears under `tools/` (OpenBao/Vault, + cluster, direct datastore); +- a new HTTP authorization decision surface appears. + +Wire it into `make check`. Review dates, if any, are reported, never used as +a calendar-day build failure. + +**Done when:** `layer.yaml` is committed, agrees with `INTENT.md`, `make check` +covers it, and a reviewer can see there are no Tooling contacts, no PEP +claim, and no decision surface. + +## T02 - Close ZONE-IN-0001 and notify gate-house + +```task +id: ZONE-WP-0003-T02 +status: todo +priority: high +``` + +Close `ZONE-IN-0001` in `intakes/intakes.md` with outcome `absorbed` / +promoted to this workplan, recording that the proposed Engine layer is +assented in this repository's own voice and that the offline PIP form is the +catalogued surface, not a contest. + +Notify `gate-house` (State Hub message or equivalent durable notice) that +zone-engine has declared Engine / PIP under v0.7 so statute §14 can stop +counting this repository among the undeclared nine. + +**Done when:** the intake file is closed with a resolution that points at +`INTENT.md` and this workplan, and the notice to `gate-house` exists. + +## T03 - Record the §10 artifacts for the 2026-08-23 layer cut + +```task +id: ZONE-WP-0003-T03 +status: todo +priority: medium +``` + +Write a short retrospective under `history/` (or a `docs/` note cited from +`INTENT.md`) that gathers the six statute §10 artifacts for the already +completed cut: + +| Artifact | Source | +| --- | --- | +| before/after `INTENT.md` | 2026-08-23 retain text vs 2026-08-29 declaration | +| client inventory | none against Tooling; offline Python tools only | +| gap inventory | none as §5.3 contacts; live Engine API is not a gap this repo currently owes | +| assent list | flex-auth / ops-warden adoption already evidenced; no new boundary moves | +| state-migration decision | `history/2026-08-23-retain-reference-decision.md` | +| permission freeze | no live API, no decision surface, no compiled stance until a later cut carries its own six artifacts | + +**Done when:** a reviewer can find all six artifacts without reconstructing +them from workplan history, and `INTENT.md` or `SCOPE.md` cites the note. + +## T04 - Align remaining consumer-facing naming + +```task +id: ZONE-WP-0003-T04 +status: todo +priority: medium +``` + +Update `README.md` so a first-time reader sees Engine / PIP, offline +reference, and `access-engine` as the ruled PDP name (currently `flex-auth`). +Do not rewrite historical evidence, workplan files, or fixture owner +identities. + +Confirm `GOAL.md` invariants already match; only patch if T01–T03 drift them. + +**Done when:** `README.md`, `INTENT.md`, `SCOPE.md`, and `GOAL.md` agree on +layer, role, and PDP name, and `git grep access-engine README.md INTENT.md +SCOPE.md GOAL.md` is the consumer-facing surface. + +## T05 - PIP claim-boundary note, without a schema + +```task +id: ZONE-WP-0003-T05 +status: todo +priority: medium +``` + +Write `docs/pip-claim-boundary.md` that: + +1. lists the facts this PIP owns today (authoritative identity, declared and + effective zone, admission result and reason, membership revision, source + and source revision); +2. maps those fields onto what a future statute §17 request-claim must carry + (issuer, freshness, zone membership — not stance, not failure mode); +3. states that stance and failure mode remain owner policy and PEP + configuration, consumed by `access-engine` as a claim or a versioned rule + (statute §18); +4. marks the mapping as a contribution to Taxonomy, not a published schema; +5. forbids a competing claim dialect and forbids compiling those facts into + registry content that determines an outcome. + +Offer the note to `gate-house` / `net-kingdom` and to `access-engine`. Do not +wait on their assent to keep the freeze. + +**Done when:** the note is cited from `SCOPE.md`, tests still pass unchanged, +and no new wire format has shipped. + +## Acceptance criteria + +- [ ] `layer.yaml` declares Engine / PIP, no Tooling contacts, no PEP map. +- [ ] `make check` fails a new undeclared Tooling client or decision surface. +- [ ] `ZONE-IN-0001` is closed on the own-voice declaration. +- [ ] `gate-house` has been notified. +- [ ] Statute §10 artifacts for the 2026-08-23 cut are gathered in one place. +- [ ] Consumer-facing docs use `access-engine` as the ruled PDP name. +- [ ] PIP facts are mapped for a future claim schema without shipping one. +- [ ] No live API, daemon, decision surface, or compiled stance was added. + +## Out of scope + +- A zone-engine API, daemon, database, controller, scheduler, or synchronous + lookup. +- Publishing a PEP unreachable-engine stance map. +- Compiling stance into registry content or changing owner policy. +- Inventing or publishing the estate request-claim schema. +- Mapping Railiance reefs onto security zones. +- The `flex-auth` → `access-engine` repository rename. +- Promoting `security-zones_v0.1` out of `proposed`. +- Archiving or renaming this Forgejo repository. +- Estate-wide reference migration of unresolved catalog entries. + +## Stop conditions + +Stop and return to the relevant owner if implementation would require any of +the following: + +- adding zone-engine to a live authorization or enforcement path; +- making a local profile authoritative over an owner policy package; +- inventing a claim schema and presenting it as estate canon; +- cataloguing this repository as PEP-shaped; +- reversing the 2026-08-23 retain / no-runtime decision without a new §10 + layer-change record and assent from the repositories whose boundaries move.