## Status

Accepted 2026-08-22 after zone-engine completed `ZONE-WP-0001-T03/T05` and published the declaration, compilation, stance, and failure-mode contract in canon revision `337484a`; zone-engine's reference compiler is revision `9b6ada7`.

## Context

ADR-0006 rejected a repo-wide `policy.enabled` switch because one boolean plus one `fail_closed` value made flex-auth a uniform dependency of every signing path, including continuity paths needed to repair that dependency. It deferred the replacement to zone-engine rather than designing an estate model here.

The owning model now exists. A zone is an evidenced workload-admission fact; control stance remains with the control owner, and dependency failure behavior remains with the PEP. Membership resolves only through an authoritative workload identity. Missing identity, membership, admission evidence, or a required floor is `unknown`, never an inferred permissive zone.

## Decision

Ops-warden adopts `security-zones_v0.1` and accepts its initial build-stage rows for the controls ops-warden owns:

- the pre-sign PEP fails open for `z0-experimental`, `z1-operational`, `z2-protected`, `z2-continuity`, and build-profile `unknown`; it fails closed for `z3-critical`;
- the agent high-risk read boundary remains enforced and fail-closed in every zone and for `unknown`;
- `warden plan` never derives `autonomous` authority from unknown zone evidence.

The implementation follows four rules:

1. `policy.enabled` and the global `policy.fail_closed` setting are retired and rejected by configuration loading. The PEP chooses failure behavior from a total per-zone map.
2. The existing compiled flex-auth registry is the resource-membership carrier. Actor resources receive `workload_id`, `security_zone`, `security_zone_admission`, and `security_zone_revision`. The dormant `trust_zone: platform` constant is removed; it is not repurposed.
3. Workload joins are explicit. Managed deployables use Repo Manager's exact `(rapp_id, workload_identity.name, deployable?)` tuple. Independent operational workloads use their owner-reviewed `tenancy.yaml`. Catalog owners distinguish `not-applicable` from applicable-but-`unknown`; no path or repository-name inference is allowed.
4. A fail-open signing result is metadata, not silence. Signature and unified audit records carry the selected zone, failure mode, outcome, and decision id when one exists.

Ops-warden itself declares `z1-operational`. That is an accuracy decision: the workload has M1 evidence and does not yet have the SLO history, on-call rotation, or exercised recovery evidence needed for z2 admission.

## Consequences

The global flip and its failure cycle no longer exist. An unknown target remains observable and follows the versioned build profile without manufacturing membership. A future organization-posture graduation changes the versioned control profile, not each workload declaration.

The flex-auth policy package still owns pre-sign stance. Ops-warden can compile and send the membership attributes, handle `allow`/`audit_only`/deny, and apply the correct PEP failure mode; it does not write flex-auth's Rego rows.

Catalog coverage is intentionally honest at adoption: exact references resolve where authoritative declarations exist, applicable lanes without one report `unknown` with a reason, and generic actions/patterns are explicitly `not-applicable`. Resolution coverage improves by adding owner declarations, never by adding heuristics here.

## Related

- `security-zones_v0.1` (net-kingdom canon revision `337484a`; zone-engine compiler revision `9b6ada7`)
- Repo Manager `helixforge.workloads.ops-warden-reference.v1` revision `890f3b0`
- NetKingdom tenancy-posture Decisions 5.6.1/5.6.2
- `WARDEN-WP-0032`
- `ADR-0004`, `ADR-0007`, and `ADR-0008`