zone-engine/GOAL.md

repo	repo_flavor	project_status	started
zone-engine	project	complete	2026-08-19

Goal — zone-engine

Outcome

Enforcement rigidity is a declared, reviewable property of a named zone rather than a boolean per repo. A control can be turned on for the band of the estate that wants its failure mode, and left advisory where that failure mode would stop the work. Deep refactors get relaxed rigidity through an exception that expires on its own.

Invariants

• access-engine remains the only policy decision point. It is the ruled name for the repository currently called flex-auth. zone-engine is the Engine-layer PIP for zone identity and membership; the effect of a zone on any decision access-engine renders is expressed in an access-engine policy package or as a claim on the request (security layer model v0.7 §6, §18).

  The first draft of this invariant said "nothing this repo builds sits synchronously in a decision path". flex-auth rejected that on review: it is a latency guarantee, not an authority one. Compiled data that determines an outcome is still deciding — it just decided earlier. Under the old wording zone-engine could compile enforced: false for a lane, flip warden sign from deny to allow with no policy-package change, and be literally compliant. Membership is ours; stance is theirs; the decision point is neither.

• Compiled, not queried. Membership reaches access-engine by compilation into the registry it already loads, as a PIP fact, never as stance. This is a consequence of the invariant above, not the invariant itself — access-engine is service_class: latency-critical and loads its registry once at process start.

• A zone that can be quietly widened is not a boundary. Every change of stance is observable, and every exception has an enforced expiry.

• Accuracy, not altitude (tenancy-posture_v0.1 §6). A repo declaring a stricter zone than it can evidence is the failure to design against, because it looks like progress.

• Placement is not posture. Reefs are a separate axis and stay separate.

• The model precedes the schema. No API, no storage, no wire format until ZONE-WP-0001 has partitioned the real estate.

Success gates

1. The model partitions today's estate — the 27 ops-warden catalog lanes, the actor inventory, the posture-carrying workloads — without a residue of unexplained exceptions.
2. A canon standard is drafted and offered to net-kingdom, in the family of tenancy-posture_v0.1.
3. At least two repos declare zones and are read by a third — a model only its author honours is not adopted.
4. ops-warden's policy.enabled is retired in favour of a zone-aware control, closing WARDEN-WP-0031-T05.
5. Whether a runtime is needed is answered on evidence from the exception lifecycle, not assumed.

Project retirement

Archive when the standard is canon, the declarations are live, and either a runtime exists with an owner or the decision that none is needed is recorded.

ZONE-WP-0002 is the final reference-contract hardening and retirement pass. It does not reopen the no-runtime decision; it makes the retained artifacts truthful enough for an explicit archive-or-maintain decision.

ZONE-WP-0003 was the owner-driven revision that followed from security layer model v0.7 being accepted. It declared the Engine/PIP layer, recorded the already-completed layer cut, and mapped membership facts for a future request-claim. It did not add a live API, a decision surface, or a PEP.

Retirement decision — 2026-08-23

Retain the repository as an offline reference-conformance repository while the canonical security-zones_v0.1 standard remains proposed. The maintainer is zone-engine; the maintenance surface is limited to canon lineage, conformance fixtures, and concrete owner-driven revisions. There is no service or routine delivery backlog. The 2026-08-29 layer declaration is one such revision: the security layer model is accepted; the zone standard is still proposed; the catalogued form stays offline.

Reassess archival when net-kingdom accepts or supersedes security-zones_v0.1, when the fixtures are durably adopted by canon/control owners, or when no adopting control needs the reference. An actual Forgejo archive or rename remains attended operator work.