Declare the layer in layer.yaml, check it against INTENT.md, and fail make check on a new Tooling client or HTTP decision surface. Record the six statute §10 artifacts for the 2026-08-23 cut, name access-engine on the README, and offer a non-schema PIP field mapping to Taxonomy. Assistant: grok Assistant-Session: 01a04ceb-0745-7ae1-9e26-0d10e5d52b8b
8.4 KiB
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 inGOAL.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
applicableandnot-applicablehandling, with unresolved facts remainingunknownand 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, andnot-applicableresults 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-engineor 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.