diff --git a/GOAL.md b/GOAL.md index 38b0be2..c13bbc6 100644 --- a/GOAL.md +++ b/GOAL.md @@ -17,26 +17,21 @@ expires on its own. ## Invariants -- **`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). +- **`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. 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 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. + 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. - **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 @@ -69,23 +64,15 @@ 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 `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. +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. -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. +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. diff --git a/INTENT.md b/INTENT.md index 1c6e2f4..d01df50 100644 --- a/INTENT.md +++ b/INTENT.md @@ -1,74 +1,37 @@ ---- -layer: Engine -role: PIP -standard: netkingdom-security-layer-model -standard_version: "0.7" -companion: net-kingdom/SECURITY-COMPANION.md ---- - # INTENT +> **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.* + > 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, confirmed 2026-08-29 +## Current disposition — 2026-08-23 The argument below is retained as design history. Its desired sentence is now -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. +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. -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. +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`. ## 1. The sentence this repo exists to make sayable @@ -76,10 +39,10 @@ shipped. > 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 was a +None of them **decides**. So every enforcement control in the estate has been a boolean over a whole repo. ## 2. Where that bit @@ -89,7 +52,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 the PDP a hard dependency of *every* `warden sign` — including the +it makes flex-auth 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 @@ -130,54 +93,44 @@ 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. **This is the PIP - fact this repository owns.** + inputs or caller context, never substitute policy subjects. - **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. 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). + remains `unknown`; it is never inferred into a permissive zone. +- **Stance per control** — enforced, advisory, or exempt. - **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 - PEP owner's**, declared ahead of time per statute §9.3. + the bite is; `fail_closed` is what turns a dead tunnel into an outage. - **Exceptions that expire without anyone remembering them.** -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. +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. ## 5. The line this repo must not cross -`access-engine` (currently `flex-auth`) is the policy decision point. It stays -the only one. +`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 `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. +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. 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. Statute §6.1 is that sentence, generalized. +deciding; it just decided earlier. **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 met for the adopted v0.1 path: +These conditions are now met for the adopted v0.1 path: Someone who has never read this repo should be able to: @@ -192,11 +145,6 @@ 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 @@ -204,9 +152,8 @@ 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 a live - engine. Retention is bounded to the proposed-standard reference need in - `GOAL.md`. + 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 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. @@ -214,27 +161,16 @@ 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", 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. + "just for now". ## 8. What this repo deliberately will not become -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. +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. ## 9. Direction @@ -249,8 +185,3 @@ 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 1415415..cf64fc9 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -8,56 +8,24 @@ ## One-liner -`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. +`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. ## 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. +needed and there is no continuing implementation backlog. 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. 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. +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. ## Capability actually present @@ -91,10 +59,6 @@ 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 | @@ -103,17 +67,13 @@ it. This repository must not ship a competing dialect. | 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 | -| 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 | +| Control stance | Owner of the control | Projects only explicit versioned owner data | | Failure behavior | Owner of the PEP | Records provenance and semantics only | -| Authorization effect | `access-engine` (currently `flex-auth`) | Makes no decision; supplies PIP facts | +| Authorization effect | Existing PDP or control owner | Makes no decision | | 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.** `access-engine` remains the only PDP for decisions it -renders. +point is neither.** `flex-auth` remains the only PDP for decisions it renders. ## Deliberately absent @@ -121,15 +81,12 @@ 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; -- estate request-claim schema, or authority to publish one; or + 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 @@ -142,24 +99,16 @@ 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, including the - security-layer-model. -- Declaring or checking this repository's Engine/PIP conformance. +- Reviewing a net-kingdom canon lifecycle/content change. - 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 `access-engine` or the owning - control. +- Asking whether a request is allowed: use `flex-auth` 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/WORK-RECORDS.md b/WORK-RECORDS.md index 14c2bb5..9cd40de 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -24,4 +24,3 @@ | task | ZONE-WP-0002-T05 | done | — | workplans/ZONE-WP-0002-reference-contract-hardening-and-retirement.md | | task | ZONE-WP-0002-T06 | done | — | workplans/ZONE-WP-0002-reference-contract-hardening-and-retirement.md | | task | ZONE-WP-0002-T07 | done | — | workplans/ZONE-WP-0002-reference-contract-hardening-and-retirement.md | -| intake | ZONE-IN-0001 | open | — | intakes/intakes.md | 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 deleted file mode 100644 index db11306..0000000 --- a/history/2026-08-29-security-layer-model-scope-against-intent.md +++ /dev/null @@ -1,221 +0,0 @@ ---- -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 12c946e..03de015 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -7,9 +7,7 @@ id: ZONE-IN-0001 kind: intake title: 'Declaration requested: state this repository''s layer in INTENT.md (security layer model §11)' -status: closed -outcome: absorbed -promoted_to: ZONE-WP-0003 +status: open origin: cross-repo origin_ref: net-kingdom security-layer-model_v0.4 §11 priority: low @@ -36,15 +34,5 @@ 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-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. +updated: '2026-08-28T21:02:13.994597Z' ``` diff --git a/workplans/ZONE-WP-0003-security-layer-model-alignment.md b/workplans/ZONE-WP-0003-security-layer-model-alignment.md deleted file mode 100644 index a06ee5c..0000000 --- a/workplans/ZONE-WP-0003-security-layer-model-alignment.md +++ /dev/null @@ -1,250 +0,0 @@ ---- -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.