# v0.7 conformance — INTENT vs SCOPE gap assessment **Date:** 2026-08-29 **Standard:** `security-layer-model_v0.7.md` (**accepted**) + `SECURITY-COMPANION.md` v0.2 **Prior:** `ADR-0010`; v0.4 and v0.6 reviews in `history/` **Method:** each v0.7 obligation checked against shipped code, not against intent. --- ## Summary ops-warden is **conformant on every obligation it can discharge alone except three**, and holds two declared §5.3 gaps that are tracked, registered and owned elsewhere. The three genuine gaps are §9.7.2 (no stated revocation visibility deadline — a MUST), §3.4 rule 1 (the agent read-boundary keys on an honour-system marker rather than an issued identity), and §9.6's cadence, which is a SHOULD for an attributive source and remains undone for an honest reason. One new obligation is not a rule at all but a role: the companion routes the entire estate to ops-warden for *how to get something done*. Nothing in the repo answers a layer or declaration question today, and that is now a discoverability gap. Four ops-warden findings were adopted into the standard between v0.4 and v0.7 — §9.1's two marks, §5's Tooling scope rule, §6.4 obligation 1's second limb, and §13.1's existence. That is the conformance loop working; it is not a reason to assume the next pass finds nothing. --- ## Obligation-by-obligation ### Conformant, shipped, evidenced | Obligation | Evidence | | --- | --- | | §11 declare layer in own voice, machine-readably | `INTENT.md` frontmatter (`layer: Staff`, `pep_shaped: true`) + `layer.yaml` — cited in §11 as the estate's reference form | | §5 every Tooling contact maps to a shape; non-Tooling recorded so the check is total | `layer.yaml` 5 contacts + 2 exclusions; `scripts/check_layer_conformance.py` | | §5.2 conduit supplies no authority | `proxy.py::_caller_env`; `tests/test_layer_conformance.py::test_conduit_supplies_no_authority_of_its_own` | | §6.4 obl. 1 no side effect without a decision **or a recorded stance** | `ca.py` writes `policy_zone`, `policy_failure_mode`, `policy_decision_id` (present only where rendered). ops-warden is the named reference for limb two | | §6.4 obl. 2 no verdict recaching | `policy.py` caches nothing — verified by inspection, not by claim | | §6.4 obl. 3 stance map published, at a path named in the declaration, equal to shipped behaviour, asserted by test | `pep-stance.yaml`, named in `layer.yaml`; test asserts equality with `PolicyConfig().failure_modes`; registered in statute §13.1 | | §9.3 stance total, per zone, no implicit default | 7 rows covering every zone plus `unknown` and `not-applicable` | | §9.6 evidence claims bounded | `wiki/AuditTrail.md` declares the attributive trade and states absence is not evidence of absence | | §9.7.1 every allow has an explicit lifetime | TTL enforced per `ActorType` — `adm` 48h, `agt` 24h, `atm` 8h | | §3.4 rule 2 tool use is a conduit or engine API | `warden access` is the conduit; `ADR-0004` enforces that tool availability is not permission | ### Declared gaps — tracked non-conformance, owned elsewhere Both registered in statute §13, intended owner `secrets-engine`, reviewed quarterly. Neither is closable by ops-warden: closing them means another repository shipping a surface. - **`VaultCA` signing write** — no engine exposes SSH-CA signing. - **`warden desk` `bao kv put`** — no engine exposes attended provisioning. Nothing in v0.7 changes their status. The right ops-warden behaviour is to keep them declared, keep the review dates honest, and not quietly grow a third. --- ## The three real gaps ### G1 — §9.7.2: no stated revocation visibility deadline (MUST) > *A **PEP** has one boundary and MUST state one deadline… an unstated deadline is > an unbounded replay window.* ops-warden states none, and the honest answer is uncomfortable: **the effective window is the certificate TTL — up to 48 hours.** A certificate issued under an allow stays valid for its full TTL even if the decision that authorized it is revoked or superseded the next minute. ops-warden has no revocation channel for an issued cert: there is no CRL, no KRL distribution, and host-side `auth_principals` is `railiance-infra`'s. This is not a documentation gap. It is a design property that has never been written down, and §9.7.2 exists precisely to force it into the open. Two things follow: 1. The deadline must be **stated** — `adm` 48h / `agt` 24h / `atm` 8h — in `pep-stance.yaml`, as what it is rather than as an aspiration. 2. Whether 48h is *acceptable* is a separate question, and it is partly `railiance-infra`'s (KRL distribution) and partly ours (TTL policy). Stating it is ours and is cheap; shortening it is a joint change. Stating a bad number is better than stating none: an unstated deadline is an unbounded replay window, and this one is bounded and already implemented. ### G2 — §3.4 rule 1: the agent boundary rests on an honour-system marker > *No standing credential. Authority is issued per task, time-bounded under §9.7, > and attributable to the principal on whose behalf it acts.* `ADR-0004`'s read-boundary triggers when `WARDEN_AGENT_ID` is set — an environment variable the agent sets **about itself**. An agent that does not set it is not recognised as an agent. ops-warden has known this (`WARDEN-WP-0033-T04` recorded it as "an honour-system marker on the ops-warden side"), and it was tolerable while no issued agent identity existed. One now does. `key-cape` accepted issuance ownership in `KEY-WP-0009-T03`: `codex-railiance-platform`, subject `service:codex:railiance-platform`, role `coding-agent`, scope `openbao:login`, 15-minute lifetime. The OpenBao side is enforced by `railiance-platform`'s policy, which is the half that actually holds. So the gap is narrower than it looks and worth stating precisely: **the OpenBao-side boundary is real; the ops-warden-side boundary is advisory.** ops-warden should key its read-boundary on the issued identity where one is present, and treat `WARDEN_AGENT_ID` as a fallback that fails *toward* the boundary rather than away from it. That is a change in this repo and does not need another repo to move. ### G3 — §9.6 emission cadence (SHOULD, for an attributive source) Unchanged from the v0.6 review and still honest: ops-warden declares no expected cadence because its signing volume is operator-driven and bursty, and a fabricated baseline generates findings that mean nothing. v0.7 makes cadence a **MUST for load-bearing sources**; ops-warden's trail is attributive, so it remains a SHOULD. Deriving a real baseline from the existing trail is tractable and is ops-warden's to do. It should be derived and declared, or explicitly deferred with a reason — not left silent, which is what it is today. --- ## The role the companion assigns, and what it costs > *"For how to get something done in NetKingdom — which lane, which credential, which > route — ask `ops-warden`. This document says what the rules are; ops-warden stewards > the paths through them."* This is the largest change in ops-warden's INTENT surface and it is not a rule, so it does not appear in any conformance check. The estate has been told to come here. **Today the repo answers credential questions and no others.** `warden route` and `warden plan` cover lanes, owners and acts. Nothing answers *"which layer am I"*, *"how do I declare"*, *"I am PEP-shaped, what do I owe"* — the questions the companion and the standard's adoption status (eight of fifteen repositories undeclared) actually generate. ops-warden has already built the reference artifacts those repositories need, and the standard points at them by name in §11 and §6.4. What is missing is the path: a discoverable route from *"I read the companion"* to *"here is the file to copy and the check to run"*. That is exactly the stewardship ops-warden claims, applied to the estate's newest rule rather than to its credential lanes. Also worth noting, and not ops-warden's to fix: §13.1's register has one row, and `ops-mason` — catalogued PEP-shaped in the same paragraph — has published nothing. The standard says one row is itself the finding. --- ## What does not need doing - **No new ADR.** `ADR-0010` holds: Staff, lanes not rules, declared gaps not exemptions. v0.2–v0.7 refined the rules around it and disturbed none of its three positions. The reviews extend it; a superseding record would add ceremony without changing a decision. - **No change to the two §5.3 gaps.** They are correctly declared and owned elsewhere. - **No re-assent.** ops-warden assented to the boundary in `ADR-0010` and has now reviewed three revisions on their merits, which is the stronger position.