by `deployable`. A catalog also declares whether its subject is workload
applicable. Resolution returns both the reference result and admission result:
-`satisfied` — the workload has an authoritative identity and evidence meeting
the declared zone's floor; `effective_zone` is the declared zone;
-`unsatisfied` — identity and membership are declared, but evidence is below
the admission floor; `effective_zone` is `unknown`;
-`unknown` — identity, membership, or a required floor/evidence input cannot be
resolved for a workload-applicable subject; `effective_zone` is `unknown`;
-`not-applicable` — the owning catalog explicitly establishes that the subject
is an action, actor, lane, pattern, or resource rather than a workload; no
zone is resolved and the control uses that subject's native identity.
`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 |
| `z2-continuity` | `M2` plus dependency/recovery evidence | `prod`; at most `confidential` data | Foundational access or recovery workloads where fail-closed dependency cycles would cause an outage |
`z2-continuity` is a sibling of `z2-protected`, not a relaxation of its
admission floor. It exists
because enforcement stance is not monotone: a tunnel or credential-issuance
path can require production 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 |
| `z2-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` resolves 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
top-level `zones:` block.
Every managed running deployable has an authoritative
`rapp-*/declarations/rapp.yaml`. Its `workload_identity.declaration_ref` points
to that declaration, and consuming catalogs reference it using the Repo Manager
v1 tuple. A pre-rapp deployable is migration debt and resolves `unknown`. An
independently governed operational execution unit that is not a managed
deployable may declare directly in its responsible repo's `tenancy.yaml`; this
does not turn a human action or infrastructure resource into a fictional rapp or
workload.
```yaml
schema_version: "0.1"
framework: netkingdom-tenancy-posture
service: ops-bridge-tunnel
role: operational-access-path
workload_identity:
name: ops-bridge-tunnel
kind: operational-control-plane
responsible_repo: ops-bridge
identity_bindings:
- scheme: ssh-certificate
authority: ops-warden
subject: agt-ops-bridge
principal_type: agent
environment: prod
tenancy:
# tenancy-posture_v0.1 content omitted
zones:
standard: security-zones_v0.1
membership: z2-continuity
responsible_party: ops-bridge
justification: foundational tunnel path must retain availability under PDP loss
context:
maturity: M2
criticality: high
data_classification: confidential
evidence:
- ref: docs/evidence/ops-bridge-tunnel-zone.md
supports: [M2, continuity-dependency, recovery]
reviewed: "2026-08-22"
review_due: "2026-11-22"
```
The `zones:` block contains only membership evidence. It MUST NOT contain
control stance, failure mode, organization posture, or exceptions.
Required fields are:
-`standard` — exactly `security-zones_v0.1`;
-`membership` — one zone id from §4;
-`responsible_party` — the party answering for this membership;
-`justification` — why the zone fits the workload's actual context;
-`context` — the evidenced `maturity`, `criticality`, and
`data_classification` used for admission. A managed workload's latter two
values must agree with its resolved rapp projection; `n/a` requires an
evidence-backed reason;
-`evidence` — one or more references and the admission facts each supports;
-`reviewed` and `review_due` — ISO dates, with review due after review.
Permanent membership changes are reviewed source changes. A change to a lower
floor also records its reason and approver in the change review. Temporary
relaxation uses an exception and never changes `membership`.
## 7. Compilation and resolved view
Compilation produces a workload-addressable resolved record. At minimum it
contains:
```yaml
workload_id: ops-bridge-tunnel
workload_ref:
applicability: applicable
rapp_id: null # required for a managed deployable
name: ops-bridge-tunnel
deployable: null # optional for a managed deployable
