# 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 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 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. 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

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.

## 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 |
| 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 | Existing PDP or control owner | Makes no decision |
| Exception grant and expiry | Designated control authority and enforcement point | Checks reusable fixtures offline |

The invariant remains: **membership is ours; stance is theirs; the decision
point is neither.** `flex-auth` 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;
- central exception store, grant workflow, clock, or expiry evaluator;
- live policy evaluation or implementation of another repository's control;
- fleet discovery, reference repair, registry publication, or workload
  migration;
- network segmentation, reef placement, tenancy, identity, or secrets service;
  or
- 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.
- Auditing why no zone-engine runtime exists.

## Not relevant when

- Determining the published rule: read net-kingdom canon.
- Asking whether a request is allowed: use `flex-auth` or the owning control.
- 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.