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