docs: reconcile delivered scope with intent

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0291a-1e87-7151-9934-fcbfe3f65eb1

history/2026-08-23-scope-against-intent.md

@@ -0,0 +1,107 @@
+# Scope assessment against `INTENT.md` — 2026-08-23
+
+## Assessment
+
+There is no open repository work. `ZONE-WP-0001` is the only workplan; it is
+`finished`, all seven tasks are `done`, and its delivery assessment is
+`DoD-Ok`. `GOAL.md` marks the project `complete`, and the checked-in work-record
+index contains no ready or in-progress item.
+
+The intended outcome was achieved, but the runtime hypothesis was falsified in
+the useful direction anticipated by `INTENT.md` §7. The repository proved that
+reviewed declarations plus enforcement-time expiry at the owning control are
+sufficient. The thing delivered here is therefore a standard source, a partial
+reference resolver, tests, and evidence—not a running zone engine.
+
+## Intent-to-outcome map
+
+| Intent claim or test | Assessment | Evidence / boundary |
+| --- | --- | --- |
+| A control can vary by workload zone rather than one repo-wide switch (§§1–2) | Met | The five-zone model and total owner-qualified profiles were adopted; ops-warden retired `policy.enabled` and global `policy.fail_closed`. |
+| The workload is the policy subject and qualifies against a floor (§3) | Met | Direct `workload_identity` plus `zones:` declarations are validated; missing facts resolve `unknown` without inference. |
+| Identity, admission, stance, failure mode, and expiring exceptions all have owners (§4) | Met by a distributed contract | zone-engine owns the identity/membership model; control owners own stance; PEP owners own failure behavior; exception expiry runs where the effect occurs. No central runtime is required. |
+| flex-auth remains the only PDP for its decisions (§5) | Met | zone-engine performs no live lookup or authorization decision. flex-auth owns its versioned policy package. |
+| Consumers can understand posture without reading this repo (§6) | Met for the adopted path | The standard is in net-kingdom canon, declarations are in owning repos, and decision/verdict evidence belongs to control owners. |
+| Exception lifecycle needs no runtime (§7 falsifier) | Falsifier triggered | `docs/exception-lifecycle-2026-08-22.md` records decision-time expiry and explicitly rejects a central service. Under the Intent, this makes the repo an archive candidate. |
+| Zones partition the real estate (§7 falsifier) | Met at model level | The estate study classifies applicable workloads and explicitly represents `unknown` and `not-applicable`; it does not manufacture zones for unresolved inventory. |
+| Two owners declare and a third reads (§7 falsifier) | Met | ops-warden and flex-auth declare; zone-engine's reference resolver reads both. |
+| No second decision point appears (§7 falsifier) | Met, with a reference-tool caveat | The local resolver projects an accepted profile for evidence, but cannot render an authorization effect and is not authoritative policy. |
+| Canon-first direction and conditional runtime (§9) | Met | Canon was published and adoption proven; T04 selected the cheaper no-runtime result. |
+
+## Gaps and residual boundaries
+
+These are gaps between the broad language of `INTENT.md`, the full canonical
+contract, and what this repository itself can execute. They are not open tasks
+in the completed workplan.
+
+### 1. Repository name and lifecycle no longer match the delivered shape
+
+The name `zone-engine` suggests a running service. No engine was needed or
+shipped. `INTENT.md` §7 says this exact outcome should lead to archival rather
+than preserving a repository for its own sake. The remaining governance choice
+is to archive it or deliberately retain it as a clearly named reference and
+evidence repository. That choice belongs outside the completed implementation
+workplan.
+
+### 2. `INTENT.md` is now historical argument, not present-state description
+
+Phrases such as “NetKingdom cannot say that today,” “the gate ... was
+deliberately not switched on,” and “a relaxation with an expiry is state”
+describe the initiating problem and hypothesis. Adoption has since made the
+sentence sayable, retired the global switch, and shown that state can live in
+versioned owner policy with expiry evaluated at the enforcement point.
+`SCOPE.md`, not those present-tense passages, must be used for current
+capability.
+
+### 3. The checked-in resolver implements only part of the resolved-view contract
+
+The reference resolver validates direct declaration files and emits an
+admission result. It does not:
+
+- resolve Repo Manager's managed-workload tuple or emit applicability and
+  `workload_ref` results;
+- discover declarations or join a fleet catalog;
+- include source revision in `membership_revision` (the digest covers the
+  workload identity and `zones:` content);
+- report membership changes against a preceding snapshot;
+- emit the full authority/provenance fields illustrated by the standard, such
+  as identity binding, policy owner, PEP owner, and policy reference; or
+- represent active exception ids and expiry in its output.
+
+Consequently it is sufficient for the recorded direct-declaration adoption
+proof, but must not be presented as the complete compiler described by the
+canonical standard.
+
+### 4. The local standard is a source snapshot, not canon
+
+`docs/security-zones_v0.1.md` remains marked `status: draft` even though the
+standard has been published and subsequently updated in `net-kingdom`. The
+published copy is authoritative. Maintaining two independently editable copies
+creates drift risk; an archived repository avoids that risk, while a retained
+reference repository needs an explicit canon-sync policy.
+
+### 5. The reference control profile could be mistaken for local stance authority
+
+`tools/resolve_zones.py` embeds the initial flex-auth and ops-warden control
+rows and emits them without policy-package provenance. This was adequate to
+prove the v0.1 adoption profile, but the owning policy packages and PEP
+configuration remain authoritative. Any future profile change must happen at
+those owners and in canon; changing this table alone must never change a live
+effect.
+
+### 6. Estate-wide completeness remains consumer migration work
+
+The model can represent resolved workloads, `unknown`, and `not-applicable`,
+but this repository does not make every catalog entry resolvable. Pre-rapp
+deployables and missing owner references remain migration debt in the owning
+catalogs and workloads. That does not require a zone-engine runtime and is not
+unclosed work in this repository.
+
+## Recommendation
+
+Treat `zone-engine` as complete and make no new runtime workplan. Prefer
+archival once its history/evidence value is accepted elsewhere. If it is kept,
+retain it explicitly as a reference-conformance repository, make net-kingdom
+canon the only consumer-facing authority, and open future work only for a
+concrete canon revision or a demonstrated adopting-control need that cannot be
+met at its existing enforcement point.