tegwick
6f667d20c2
Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a0291a-1e87-7151-9934-fcbfe3f65eb1
114 lines
5.4 KiB
Markdown
114 lines
5.4 KiB
Markdown
# 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.
|