zone-engine/SCOPE.md

# 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 declaration is `layer.yaml`. `tools/check_layer_conformance.py`
fails if that file disagrees with `INTENT.md` frontmatter, if a Tooling-layer
client appears under `tools/`, or if an HTTP authorization decision surface
appears. The six statute §10 artifacts for the already-completed layer cut
are `history/2026-08-29-layer-change-artifacts.md`.

`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 unit
  tests covering resolver, exceptions, lineage, and layer conformance.

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 a
statute §17 request-claim. Taxonomy owns that schema and has not published
it. The field mapping offered to Taxonomy is `docs/pip-claim-boundary.md`.
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.
- Mapping those membership facts onto a future request-claim
  (`docs/pip-claim-boundary.md`) without shipping a schema.
- 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.