`unknown` is a result, not a zone. A control MUST declare an explicit treatment
for it. That treatment may deny, escalate, or use a reviewed build-stage rule;
it never manufactures membership and never grants an exception.
## 4. Zone catalog
The initial catalog follows the estate's existing `M0`–`M3` maturity ladder and
adds one non-monotone continuity band required by ops-warden `ADR-0006`.
| Zone id | Admission floor | Environment/data boundary | Purpose |
| --- | --- | --- | --- |
| `z0-experimental` | `M0` promotion evidence | Synthetic only; no real credential or user data | Experiments where advisory controls preserve iteration speed |
| `z1-operational` | `M1` promotion evidence | Production secret handling for at most `internal` data | Early operational workloads with an owned front door |
| `z2-protected` | `M2` promotion evidence | `prod`; at most `confidential` data | Production workloads requiring review, SLO/on-call, and incident readiness |
| `z3-critical` | `M3` promotion evidence | `prod`; at most `restricted` data | Critical or regulated workloads with the strongest normal failure behavior |
| `z3-continuity` | `M3` plus dependency/recovery evidence | `prod`; at most `restricted` data | Foundational access or recovery workloads where fail-closed dependency cycles would cause an outage |
`z3-continuity` is a sibling of `z3-critical`, not a lower rung. It exists
because enforcement stance is not monotone: a tunnel or credential-issuance
path can require M3 scrutiny while deliberately remaining fail-open for one
availability-sensitive control. Placement on a reef is never evidence for any
zone.
### 4.1 Context floor
The declared zone must be at least as strict as the workload context requires.
The context floor is the maximum of every resolved input:
| `criticality` | Minimum maturity |
| --- | --- |
| `low` | `M0` |
| `medium` | `M1` |
| `high` | `M2` |
| `critical` | `M3` |
Data-class floors are consumed from the canon-owned classification mapping; the
current `synthetic → M0`, `internal → M1`, `confidential → M2`, and
`restricted → M3` mapping is already used by ops-warden. An absent or unresolved
floor makes admission `unknown`. In particular, `public` is disclosure policy
and `synthetic` is data origin: they are not aliases, and this standard does not
invent a floor while info-tech-canon's ruling is pending.
`organization_posture` may select a versioned control profile, but it never
changes identity, membership, or admission.
## 5. Stance and failure-mode model
Every owner-qualified control publishes a total mapping over all zone ids plus
`unknown`. There is no implicit default.
-`enforced` — the control's deny or escalation effect changes the outcome;
-`advisory` — the control evaluates fully and records the outcome it would
have produced, but does not block;
-`exempt` — the control is deliberately not evaluated for this zone and emits
the versioned exemption reason.
Failure mode is separate and PEP-side:
-`fail_closed` — an unavailable or invalid evaluator produces the control's
safe blocking/escalation outcome;
-`fail_open` — the PEP proceeds and records that the control was unavailable.
`exempt` has no failure mode. A local control with no remote dependency uses
`fail_closed` to describe evaluator errors. Changing stance is a policy-package
change owned by the control owner, not a membership change.
### 5.1 Initial build-stage control profile
This profile is the v0.1 proposal for the first consumer. It is not stored in a
workload's `zones:` declaration. flex-auth owns the pre-sign rows; ops-warden
owns the other rows and every PEP failure mode.
| Zone | flex-auth pre-sign stance / ops-warden PEP | agent high-risk read boundary | `warden plan` zone rule |
| `z2-protected` | `enforced` / `fail_open` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches |
| `z3-critical` | `enforced` / `fail_closed` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches |
| `z3-continuity` | `enforced` / `fail_open` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches |
| `unknown` | `advisory` / `fail_open` under the versioned `build` profile | `enforced` / `fail_closed` | `enforced`; never `autonomous` from zone evidence |
The `unknown` pre-sign treatment is an explicit organization-build policy, not
a permissive membership default. It must change through a versioned control
profile when the organization posture graduates.
The agent read boundary stays enforced in every zone: build-stage permissiveness
does not extend to disclosing high-risk credentials. For a missing lane risk:
-`z0-experimental` may resolve to `standard` only when admission proves the
lane can expose synthetic material exclusively;
-`z1-operational` and `z2-protected` resolve to at least `high`;
-`z3-critical` and `z3-continuity` resolve to `critical`, treated by the
boundary as at least `high`; and
- unresolved membership resolves to at least `high`.
An explicit grade always remains preferable. `accepted` is an acceptance record,
not a risk grade.
## 6. Declaration in `tenancy.yaml`
For a single-service declaration, `zones:` is a sibling of `tenancy:` and
`workload_identity`. For a `services:` declaration, both `workload_identity` and
`zones` occur inside the same service entry. A multi-service file MUST NOT use a
