7 changed files with 88 additions and 705 deletions
--- 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
+- **`flex-auth` remains the only policy decision point.** zone-engine is
-  name for the repository currently called `flex-auth`. zone-engine is the
+  authority over zone **identity and membership**; the **effect** of a zone on
-  Engine-layer **PIP** for zone **identity and membership**; the **effect** of
+  any decision flex-auth renders is expressed in a flex-auth policy package.
  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 policy-package change, and be literally
+  from deny to allow with no flex-auth policy change, and be literally
-  compliant. Membership is ours; stance is theirs; the decision point is
+  compliant. Membership is ours; stance is theirs.
-  neither.
+- **Compiled, not queried.** Membership reaches flex-auth by compilation into
- **Compiled, not queried.** Membership reaches `access-engine` by compilation
+  the registry it already loads. This is a *consequence* of the invariant
-  into the registry it already loads, as a PIP fact, never as stance. This is
+  above, not the invariant itself — flex-auth is `service_class:
-  a *consequence* of the invariant above, not the invariant itself —
+  latency-critical` and loads its registry once at process start.
  `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
@ -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
+canonical v0.1 standard remains `proposed`. The maintainer is zone-engine; the
-zone-engine; the maintenance surface is limited to canon lineage, conformance
+maintenance surface is limited to canon lineage, conformance fixtures, and
-fixtures, and concrete owner-driven revisions. There is no service or routine
+concrete owner-driven revisions. There is no service or routine delivery
-delivery backlog. The 2026-08-29 layer declaration is one such revision: the
+backlog.
 security layer model is **accepted**; the zone standard is still **proposed**;
 the catalogued form stays offline.
-Reassess archival when net-kingdom accepts or supersedes `security-zones_v0.1`,
+Reassess archival when net-kingdom accepts or supersedes v0.1, when the fixtures
-when the fixtures are durably adopted by canon/control owners, or when no
+are durably adopted by canon/control owners, or when no adopting control needs
-adopting control needs the reference. An actual Forgejo archive or rename
+the reference. An actual Forgejo archive or rename remains attended operator
-remains attended operator work.
+work.
--- 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
+sayable: the standard is in net-kingdom canon, ops-warden and flex-auth have
-have adopted it, the repo-wide switch is retired, and exception expiry is
+adopted it, the repo-wide switch is retired, and exception expiry is enforced
-enforced at each owning decision or enforcement point.
+at each owning decision or enforcement point.
-The runtime hypothesis was falsified. That was a layer change in practice
+The runtime hypothesis was falsified. zone-engine is retained only as an
-(statute §10 cites this case). zone-engine is retained as an Engine/PIP whose
+offline reference-conformance repository while canon v0.1 remains proposed; it
-surface is offline reference conformance while `security-zones_v0.1` remains
+is not an engine, PDP, exception service, or consumer policy owner. Current
-proposed. It is not a PDP, not a PEP, not an exception service, and not a
+capability is `SCOPE.md`, and the retain/archive triggers are in `GOAL.md`.
 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
@ -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
+At inception NetKingdom could not say that. It could say how exposed a workload was
-was (environment posture), how ready it is (`M0`–`M3`), and what state the
+(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
+  inputs or caller context, never substitute policy subjects.
  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. Same
+  remains `unknown`; it is never inferred into a permissive zone.
-  authoritative inputs, same result.
+- **Stance per control** — enforced, advisory, or exempt.
 - **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
+  the bite is; `fail_closed` is what turns a dead tunnel into an outage.
  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 live
+The last was the runtime hypothesis. A standing classification needs no engine
-engine — canon plus a declaration file covers it, which is exactly how tenancy
+— canon plus a declaration file covers it, which is exactly how tenancy posture
-posture works. The implementation proved that exception state can remain with
+works. The implementation proved that exception state can remain with the
-the control owner when `not_after` is evaluated where the effect occurs. That
+control owner when `not_after` is evaluated where the effect occurs. That gives
-gives it an owner, audit trail, and enforced deadline without a central service.
+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
+`flex-auth` is the policy decision point. It stays the only one.
 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`
+of a zone on a decision flex-auth renders belongs in a flex-auth policy package,
-policy package, because the decision envelope stamps `matched_policy_version`
+because flex-auth's decision envelope stamps `matched_policy_version` and
-and `policy_package` — and registry content appears nowhere in that provenance.
+`policy_package` — and registry content appears nowhere in that provenance. Put
-Put stance in the registry and two decisions with the same policy version and
+stance in the registry and two decisions with the same policy version and the
-the same request can differ, with nothing in the audit trail explaining why.
+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
+  The honest outcome is canon plus offline conformance tooling, not an engine.
-  engine. Retention is bounded to the proposed-standard reference need in
+  Retention is bounded to the proposed-standard reference need in `GOAL.md`.
  `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
+  "just for now".
  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 a PEP. Not network segmentation — "zone" is overloaded and the
+Not a PDP. Not network segmentation — "zone" is overloaded and the routing sense
-routing sense is someone else's word. Not a placement model: reefs answer
+is someone else's word. Not a placement model: reefs answer *where a thing runs*
-*where a thing runs* and are Railiance's, and the fact that `reef-railiance`
+and are `repo-manager`'s, and the fact that `reef-railiance` caps availability
-caps availability for everything bound to it is a canon composition problem
+for everything bound to it is a canon composition problem (`NK-WP-0027`), not
-(statute §20.3, originally `NK-WP-0027`), not ours. Not an owner of anyone's
+ours. Not an owner of anyone's controls — the controls stay with the repos that
-controls — the controls stay with the repos that enforce them; this model only
+enforce them; this model only says where they bite.
 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
@ -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.
--- a/SCOPE.md
+++ b/SCOPE.md
@ -8,56 +8,24 @@
 ## One-liner
-`zone-engine` is the Engine-layer **PIP** for NetKingdom zone identity and
+`zone-engine` is the retained reference-conformance repository for NetKingdom
-membership, retained as an offline reference-conformance repository. It does
+security-zone membership, admission, owner-provenanced control profiles, and
-**not** run a live engine, render a policy decision, or cause a protected side
+time-boxed exception semantics. It does **not** run an engine or make policy
-effect.
+decisions.
 ## 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.
+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
+tooling. Retention is not service ownership. A future canon lifecycle change,
-model does not reopen the no-runtime decision; it names the retained form as
+an owner-requested conformance revision, or evidence that an adopting control
-the Engine/PIP this repository already is.
+cannot enforce the contract at its existing point are the only normal change
-
+triggers. Archival remains an attended action once the reference artifacts are
-Normal change triggers remain: a canon lifecycle or content change, an
+durably handed off or no longer needed.
 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
@ -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 |
+| Control stance | Owner of the control | Projects only explicit versioned owner data |
 | 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 | `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
+point is neither.** `flex-auth` remains the only PDP for decisions it renders.
 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
+- Reviewing a net-kingdom canon lifecycle/content change.
  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 `access-engine` or the owning
+- Asking whether a request is allowed: use `flex-auth` or the owning control.
  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.
--- 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 |
--- a/history/2026-08-29-security-layer-model-scope-against-intent.md
+++ b/history/2026-08-29-security-layer-model-scope-against-intent.md
@ -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`.
--- 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
+status: open
 outcome: absorbed
 promoted_to: ZONE-WP-0003
 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'
+updated: '2026-08-28T21:02:13.994597Z'
 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.
 ```
--- a/workplans/ZONE-WP-0003-security-layer-model-alignment.md
+++ b/workplans/ZONE-WP-0003-security-layer-model-alignment.md
@ -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.