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.