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

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