--- id: WARDEN-WP-0040 type: workplan title: "Adopt unknown -> fail_closed behind signing-target classification coverage" domain: infotech repo: ops-warden status: blocked flavor: planning depends_on: - WARDEN-WP-0032 - WARDEN-WP-0034 owner: ops-warden topic_slug: netkingdom planning_priority: P1 depends_on_workplans: - WARDEN-WP-0032 - WARDEN-WP-0034 created: "2026-09-09" updated: "2026-09-28" state_hub_workstream_id: "c8ee441e-1be1-5219-910c-e79ff23cc9ec" --- # WARDEN-WP-0040 — `unknown` → `fail_closed`, in the right order security-layer-model v0.8 §6.4 obligation 3 (proposed, 2026-09-06) rules that `unknown` is not a zone and must resolve to `fail_closed`. ops-warden's `pep-stance.yaml` declares `unknown: fail_open` under `ADR-0009`. **We agree with the rule.** `history/2026-09-09-layer-model-v08-review.md` records the assent and why our falsifier check failed: the cell governs certificate issuance, not a §5.1 read-only diagnostic, so nothing rescues it. **We disagree with adopting it first.** Measured 2026-09-09: of four signing targets, zero resolve to a zone, three are `unknown`, one is `not-applicable`. Flipping the cell today makes flex-auth a hard dependency of essentially every certificate — `ADR-0006`'s rejected configuration, reached by a different route, including the continuity path needed to repair flex-auth itself. So: coverage first, then the cell. That ordering is the whole holding of `ADR-0006` and the reason `ADR-0009` replaced a global switch with a zone map. ## Tasks ```task id: WARDEN-WP-0040-T01 status: wait priority: high state_hub_task_id: "611f0901-9fb5-5954-8dd0-a860c5f0cbec" ``` **Classify the continuity path before anything else changes.** The deadlock is specific and worth naming before it is designed around: flex-auth unreachable → operator needs an SSH certificate to reach the host → target is `unknown` because nobody classified the repair path → `fail_closed` denies it. `z2-continuity` exists for this and its stance is `fail_open`, so the fix is classification, not an exception. Determine which actor(s) constitute the repair path, establish whether the declaration is ops-warden's to make (our own `tenancy.yaml` covers ops-warden as a workload; the actors' target workloads may not be ours), and route what is not. Blocks T03. Converting the cell with the repair path unclassified is the one outcome this workplan exists to prevent. ```task id: WARDEN-WP-0040-T02 status: wait priority: high state_hub_task_id: "54ad4864-7bcf-592e-a187-9239a81a0b11" ``` **Raise signing-target coverage, by asking owners — never by inferring.** Three actor resources report `workload_resolution_absent`: `agt-codex-interhub-bootstrap`, `agt-state-hub-bridge`, `atm-backup-daily`. Their owners (ops-bridge and the backup execution unit among them) have not published an authoritative workload identity declaration. `ADR-0009` rule 3 forbids closing this with path or repository-name inference, and that prohibition holds under pressure from this workplan specifically — adopting a stricter stance is not a licence to manufacture the membership that makes it survivable. Route to each owner with the concrete consequence: while the declaration is absent their actor cannot be issued a certificate during a flex-auth outage once the cell converts. That is a better ask than a generic request to publish a declaration, and it is true. Report coverage with `scripts/report_workload_join.py`; this task is done when coverage is stated, not when it reaches a threshold — the threshold is T03's gate, and owners may legitimately decline. ```task id: WARDEN-WP-0040-T03 status: wait priority: high state_hub_task_id: "93eaf1f2-daaa-5e22-8804-85ca9433571c" ``` **Convert the cell and supersede `ADR-0009`'s unknown row.** Gated on T01, and on v0.8 (or its successor) reaching `accepted`. Do not convert against a `proposed` standard. `ADR-0009` is `owner: ops-warden`, so changing it means a superseding ADR, never an in-place edit (`.claude/rules/architecture.md`). The superseding record should carry the v0.8 argument rather than restate it: unknown is not a zone, so a §9.3 per-zone trade was never made for that request. `pep-stance.yaml` is asserted equal to `PolicyConfig.failure_modes` by `tests/test_layer_conformance.py`, so the map and the code convert in one commit or the test fails — which is the property that makes the map worth publishing. ```task id: WARDEN-WP-0040-T04 status: done priority: medium state_hub_task_id: "222a8c5d-0c0f-5a1d-98d8-02be7dca3358" ``` **Return findings to gate-house and track the transition ask.** Sent 2026-09-09 with the review. Two asks, in preference order: obligation 3 names a dated transitional state gated on coverage; or failing that, §13.1 records classification coverage alongside stance, so a register row cannot read `unknown: fail_closed` while every target is unknown. If both are declined, that is an answer and this workplan proceeds unchanged — the cell stays a **declared gap** under §11 with this workplan as its route, which is what the `declared-gap` mark (our own v0.6 finding) exists to express. **Answered 2026-09-09 — GH-DEC-2026-011.** Ask 1 declined, ask 2 adopted; standard amended at `net-kingdom@64394e9`. Ask 1's refusal is correct and we are not appealing it: a sanctioned transitional `fail_open` is indistinguishable at runtime from the stance the rule forbids, and would make the rule optional at the only moment it costs anything. Ask 2 gave us what we actually needed — §13.1 carries a Coverage column with this repo's figures as its first entries, guarded so that coverage never softens a stance, never gates one, and never makes a non-conformant cell conformant. The reversal condition on that column binds ops-warden first, since the column exists because we asked: if a row is ever argued conformant *because* its coverage is low, the column comes out. Our row reads non-conformant and low-coverage, and the second is not a defence of the first. gate-house confirmed explicitly that they are **not** asking for the cell to be flipped before coverage exists, and that this workplan's order is right. The cell stays a declared gap under §11 with WP-0040 recorded as its route — the outcome this task named as acceptable if both asks were declined, reached with one of them adopted. T01–T03 are unchanged and still gate the conversion. Coverage is now measured rather than asserted (`scripts/report_coverage.py`), so T02's reporting obligation has a tool behind it and the published figure cannot drift from the register's. ### 2026-09-28 loose-end review T04 is done: GH-DEC-2026-011 already answered both transition asks on September 9; the accepted coverage column and declared-gap disposition are recorded above. No additional response is required to meet that task's acceptance criterion. T01/T02 now wait; the workplan is blocked. Re-ran both coverage reports: signing targets = 0 resolved / 3 unknown / 1 not-applicable; routing lanes = 3 resolved / 20 unknown / 15 not-applicable. Refreshed pep-stance.yaml's measured date. These figures describe the checked-in registry and local owner declarations, not a live PDP query. No zone membership was inferred or changed. The exact missing workload resolutions are `ops-bridge-tunnel` for `agt-state-hub-bridge`, `codex-interhub-bootstrap` for `agt-codex-interhub-bootstrap`, and `backup-daily` for `atm-backup-daily`. The seed inventory's `adm-example` is not an admitted repair actor. Warden's own workload declaration cannot classify those target workloads. T01 needs an owner-declared continuity actor/target and its authoritative z2-continuity resolution; T02 retains the owner-routing/declaration follow-up (ops-bridge, the Inter-Hub execution owner and the backup execution owner). Without it, changing unknown to fail_closed would deny their issuance during a PDP outage. Coverage reporting is complete, but owner coordination is not. T03 also remains gated on standard acceptance: the local authoritative net-kingdom/canon/standards/security-layer-model_v0.8.md still says proposed. No superseding ADR or runtime stance change is warranted before these gates.