zone-engine/docs/exception-lifecycle-2026-08-22.md

Time-boxed security-zone exceptions — ZONE-WP-0001-T04

Decision date: 2026-08-22
Decision: the exception lifecycle does not require a zone-engine runtime.

An exception is a temporary relaxation of one control for workloads already admitted to a named security zone. It does not change membership, lower an admission floor, or create a temporary-sounding zone. Membership remains a declared workload fact. The control owner remains the authority for the effect.

1. Grant authority

The workload's responsible party may request an exception. Only the authority designated by the control owner may grant it, because that owner owns the base stance and the enforcement point that must apply the relaxation. For a failure-mode relaxation, the grant authority is the owner of the policy enforcement point (PEP), never the PDP.

One person may currently perform both roles in this founder-operated estate, but the record still names requested_by and granted_by separately. A declarer cannot grant itself an exemption merely by changing its zone membership.

Each control declares a maximum_exception_duration. If it declares no maximum, it permits no exceptions. A grant beyond the declared maximum is invalid rather than silently shortened.

2. Minimum record

This is a conceptual record for the canon draft, not an API or storage schema. Every implementation must preserve these facts in machine-readable form:

Fact	Rule
exception_id	Stable and unique; renewed grants get new ids
security_zone	The admitted zone whose normal rule is being relaxed
control	Stable owner-qualified control id
workloads	Authoritative workload ids; an empty or unresolved subject is invalid
base	The stance and, where relevant, PEP failure mode that auto-restores
relaxation	Explicit advisory or exempt stance and/or PEP-side failure mode
justification	The bounded work that requires the relaxation
requested_by / granted_by	Auditable responsible parties
issued_at / not_before / not_after	UTC instants; not_after is exclusive
maximum_duration_policy	Versioned rule against which duration was checked
change_ref	Reviewed source change that introduced the grant

A grant may only relax a named control. Promotion to a stricter stance is an ordinary policy change, not an exception. Wildcard workload scope is forbidden: the work that needs relief must be named, and unknown membership never inherits a permissive zone or exception.

3. Enforced expiry

At every decision or enforcement attempt, an exception applies only when all of the following are true:

1. its record is valid and was granted by the control's designated authority;
2. the current authoritative workload and zone match its scope;
3. not_before <= now < not_after; and
4. its duration does not exceed the referenced maximum.

Missing, malformed, unresolved, or unevaluable facts make the exception inactive. The enforcement point applies the base stance and failure mode. Clock failure must never preserve the relaxation.

Expiry is an automatic return to the base rule. It does not block waiting for a renewal, and it does not require a commit, image rebuild, rollout, scheduler, or human reminder. Renewal is a new reviewed grant with a new id; the expired record remains in history.

No authority created under an exception may outlive it. A certificate, token, lease, session, or other durable result must have an expiry no later than the exception's not_after, or the enforcement point must re-evaluate the exception before each use. Otherwise the timestamp would expire while its effect remained live.

4. Placement by control

Control kind	Grant representation	Expiry evaluator	Required evidence
flex-auth decision	Versioned flex-auth policy package	Rego decision time (time.now_ns())	Decision envelope includes policy package/version and active exception id/expiry
ops-warden CLI decision	Versioned ops-warden control data	CLI at each invocation	Verdict reasons includes active exception id/expiry
PEP failure mode	Versioned consumer configuration	PEP when the PDP/control is unreachable	PEP audit record includes exception id/expiry and fallback taken

This placement preserves the authority boundary: zone-engine standardizes the lifecycle, while each control owner represents and evaluates the effect where that control already runs. In particular, fail-open cannot be implemented by flex-auth because no PDP decision exists when flex-auth is unreachable.

The current flex-auth deployment loads registry and policy once at process start. Granting therefore costs rebuild and rollout, but a timestamp evaluated at decision time still lapses without either. An inert registry flag would not; it is prohibited for exceptions.

5. Visibility

Someone who did not grant an exception must be able to discover it in two places:

• the reviewed, versioned source record owned with the control, including expired records in history; and
• the machine-readable decision or verdict whenever the exception changes an outcome, including exception_id and not_after.

Control builds must also produce a machine-readable inventory of active and future grants and reject overlaps that would make the selected relaxation ambiguous. Near-expiry reporting is useful operationally but is not the expiry mechanism.

6. Runtime decision

A central zone-engine service would not enforce expiry more reliably. It could not alter flex-auth's digest-pinned, load-once artifacts at the deadline, and a synchronous lookup would add a new availability dependency while crossing the PDP authority boundary. The enforcement points already have the clocks and the decision context needed to make a compiled not_after self-expiring.

Therefore T04 selects reviewed declarations plus enforcement-time timestamp evaluation. zone-engine needs a canon contract and conformance fixtures, not a runtime. This decision can be reopened only if a real adopting control cannot evaluate time at the point where the relaxation takes effect.