# SCOPE > What this repository can do, when it is relevant, and when it is not. > The historical argument is `INTENT.md`; completed gates and retirement are > recorded in `GOAL.md`. --- ## 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. ## 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. 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. ## Capability actually present This repository provides: - a non-authoritative pointer and machine-checked lineage record for the canonical `net-kingdom/canon/standards/security-zones_v0.1.md`; - an offline resolver for direct declarations and caller-supplied Repo Manager v1 workload projections; - explicit `applicable` and `not-applicable` handling, with unresolved facts remaining `unknown` and no path, repo, reef, actor, or lane inference; - validation of authoritative identity bindings, zone declarations, review dates, context floors, and continuity evidence; - canonical `satisfied`, `unsatisfied`, `unknown`, and `not-applicable` results with workload references, identity bindings, guarantees, sources, and source revisions; - deterministic membership revisions bound to canonicalized identity, membership, workload reference, and source revision; - deterministic first/previous-snapshot addition, removal, and change reports; - optional control projection from an explicit, total, versioned profile that names policy owner, PEP owner, and policy reference for every row; - an offline exception checker with an explicit evaluation instant, covering grant authority, maximum duration, exclusive expiry, overlap, renewal, wildcard rejection, and durable-authority bounds; and - reusable manifests, profiles, exception fixtures, evidence, and 29 unit tests. The resolver consumes already-located declarations and already-resolved workload-reference projections. It does not discover a fleet, repair an 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 | | --- | --- | --- | | Workload identity and requested membership | Workload's responsible repo | Reference-validates supplied facts | | 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 | | Failure behavior | Owner of the PEP | Records provenance and semantics only | | Authorization effect | `access-engine` (currently `flex-auth`) | Makes no decision; supplies PIP facts | | Exception grant and expiry | Designated control authority and enforcement point | Checks reusable fixtures offline | | Reef placement vs zone floor | Railiance / canon composition (statute §20.3) | Keeps the axes separate; does not compose them | The invariant remains: **membership is ours; stance is theirs; the decision point is neither.** `access-engine` remains the only PDP for decisions it renders. ## Deliberately absent 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 - authority to publish canon or select a consumer's stance and failure mode. Exception expiry remains enforced at decision or enforcement time by each owning control. The offline checker is conformance evidence, not a live decision point. ## Relevant when - Reproducing or extending v0.1 conformance fixtures. - 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. - 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. - 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.