Align INTENT and SCOPE to layer model v0.7; assess gaps; open WARDEN-WP-0034

The standard is accepted at v0.7, with SECURITY-COMPANION.md v0.2 as its
operative form. Four ops-warden findings were adopted 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 — and both ops-warden declaration artifacts are now cited in
the text as the estate's reference forms.

INTENT.md gains frontmatter (layer: Staff, pep_shaped: true) because §11 requires
a machine-readable declaration and prose cannot distinguish a declaration from a
transcribed review. The note now covers the agent principal (§3.4), the PEP
shape, the attributive evidence position, and the role the companion assigns:
the estate is told to ask ops-warden which lane, which credential, which route.

SCOPE.md records what is actually shipped against v0.7 and the honest conformance
state — declared gap, which is tracked non-conformance, not conformance.

The assessment checked every obligation against shipped code rather than intent.
Three gaps survive:

- §9.7.2 requires a PEP to state one revocation visibility deadline. Ours is
  unstated, and the honest value is uncomfortable: the cert TTL, up to 48h. A
  cert outlives revocation of the decision that authorized it — no CRL, no KRL
  distribution. That is a design property never written down, which is exactly
  what §9.7.2 exists to force into the open.
- §3.4 rule 1 forbids standing credentials and requires issued, attributable
  authority. ADR-0004's boundary keys on WARDEN_AGENT_ID, which an agent sets
  about itself. key-cape now issues a real coding-agent identity, so the
  ops-warden half can stop being advisory.
- §9.6 cadence remains undeclared. Attributive, so SHOULD not MUST, but silence
  through two reviews is the one outcome that is not defensible.

WARDEN-WP-0034 addresses all three, plus the discoverability gap the companion
creates and two items to route rather than absorb.

402 tests pass, ruff clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YWBMovyFoy9RRrfL7zKvPJ

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014535@bnt-lap001
Assistant-Session: d0036016-73e8-4da1-8e47-563e3ab39a3c

INTENT.md

@@ -1,34 +1,67 @@
+---
+layer: Staff
+role: null                    # Engines only: PDP | PIP | Evidence | Lifecycle
+pep_shaped: true              # §6.4 — issuing a certificate is a protected side effect
+standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
+standard_version: "0.7"
+companion: net-kingdom/SECURITY-COMPANION.md
+declaration: layer.yaml
+pep_stance: pep-stance.yaml
+assent: docs/adr/ADR-0010
+---
+
 # INTENT
 
-> **Layer: Staff.** ops-warden is a Staff repository under the NetKingdom
-> IT-security layer model (Taxonomy -> Tooling -> Engines -> Staff, layered by
-> determinism and by the kind of artifact each layer produces):
-> `net-kingdom/canon/standards/security-layer-model_v0.4.md` (**accepted**), owned by
-> gate-house, ratified as `gate-house/decisions/decisions.md` GH-DEC-2026-001.
-> ops-warden's assent is recorded there as `ADR-0010`.
+> **ops-warden is Staff, and PEP-shaped.** Declared here in its own voice, per
+> `security-layer-model_v0.7` §11 — a layer stated *about* a repository by another
+> repository is not a declaration. The standard is **accepted**; its operative form
+> is `net-kingdom/SECURITY-COMPANION.md`. ops-warden's assent is `ADR-0010`, and its
+> reviews of v0.4, v0.6 and v0.7 are in `history/`.
 >
-> **The binding rule: Staff never touches Tooling directly. It acts only through
-> Engine APIs.** ops-warden holds no state another layer depends on at runtime and
-> renders no authorization decision — it consumes them from access-engine.
+> **Staff** because ops-warden's core function is judgement, not computation: it
+> decides which lane a need belongs to and stewards the paths through the estate's
+> rules. Its artifacts are runbooks, routing decisions, workplans. **PEP-shaped**
+> because issuing a certificate is a protected side effect — a shape, not a layer
+> (§6.4). ops-warden renders no authorization decision and never will; it consumes
+> them from `access-engine`.
 >
-> **Declared exception (standard section 5).** `src/warden/vault.py` (`VaultCA`) is a
-> direct OpenBao client that performs a write, and `warden desk` shells `bao kv put`
-> for paste-once provisioning. Both are non-conformant. Intended owner:
-> **secrets-engine**; blocked on: no engine exposes an SSH certificate signing
-> surface; reviewed quarterly. `src/warden/taint.py` reads KV metadata only, declared
-> under the read-only observation allowance. `warden access --fetch/--exec/--wrap`
-> runs the owner's tool under **the caller's** identity and supplies no authority of
-> its own (`ADR-0002`).
+> **The estate's front door for paths.** The companion routes the whole estate here:
+> *"For how to get something done — which lane, which credential, which route — ask
+> `ops-warden`. This document says what the rules are; ops-warden stewards the paths
+> through them."* That is a standing obligation, not a compliment: every rule
+> gate-house writes needs a path someone can actually walk, and ops-warden owes the
+> estate that path.
 >
-> **The declaration is `layer.yaml`, not this note.** v0.4 §5.3 requires a gap to
-> carry `capability`, `intended_owner`, `blocked_on` and `review` *machine-readably*,
-> and §11 makes "every direct Tooling client maps to a declared §5.1/§5.2/§5.3 entry"
-> a mechanical check. `layer.yaml` is that map; `scripts/check_layer_conformance.py`
-> and `tests/test_layer_conformance.py` enforce it, so a new undeclared OpenBao
-> client fails on the commit that introduces it.
+> **The declarations are files, not this note** — prose cannot distinguish a
+> declaration from a transcribed review (§11):
 >
-> Assent, reasoning, and the amendment offered back to gate-house — adopted as
-> v0.4 §5.3: `history/2026-08-28-security-layer-model-assent.md` and `ADR-0010`.
+> | File | Declares | Enforced by |
+> | --- | --- | --- |
+> | `layer.yaml` | every Tooling contact, mapped to a §5.1/§5.2/§5.3 shape, plus the non-Tooling clients so the check is total | `scripts/check_layer_conformance.py`, `tests/test_layer_conformance.py` |
+> | `pep-stance.yaml` | the unreachable-engine stance map (§6.4 obl. 3), total per zone | test asserts the published map **equals** the shipped default |
+> | `tenancy.yaml` | tenancy posture, and `z1-operational` zone membership | `ADR-0009` |
+>
+> Both are cited in the standard as the estate's reference forms (§11, §6.4, §13.1).
+>
+> **Two declared engine gaps (§5.3), tracked non-conformance and not conformance.**
+> `VaultCA` signs over a direct OpenBao client and `warden desk` shells `bao kv put`.
+> Intended owner **secrets-engine**; blocked on no engine exposing an SSH-CA or
+> attended-provisioning surface; reviewed quarterly; registered in statute §13.
+> ops-warden keeps signing while the gap is open — refusing would remove production
+> host access to close a documentation gap.
+>
+> **The agent principal (§3.4).** ops-warden is operated by agents as well as people,
+> and they share the layer but not the blast radius. No standing credential; tool use
+> is a conduit or an engine API and there is no third route; **tool availability is
+> not permission**, which is exactly what `ADR-0004`'s read-boundary enforces; agent
+> memory is not a state plane. Session semantics belong to `glas-harness`, not here.
+>
+> **Evidence (§9.6).** ops-warden's audit trail is **attributive**, not load-bearing:
+> no control branches on the presence of a signing record. Emission is deliberately
+> non-atomic so an audit-store failure cannot remove production host access — a trade
+> the standard sanctions, declared in `wiki/AuditTrail.md`, registered in §13. If any
+> future control ever gates on this trail, that trade must be revisited before it
+> ships.
 
 > This file captures **why this repository exists**, the **direction it is
 > moving toward**, and the **kind of system it is meant to become**.
@@ -110,7 +143,7 @@ owns one lane and points at the rest:
 ## Lane routing — who owns which need
 
 **This is a runbook, not doctrine.** Security doctrine, the authority model, and the
-security curriculum are **gate-house's** (`security-layer-model_v0.1` section 8).
+security curriculum are **gate-house's** (`security-layer-model_v0.7` §8).
 ops-warden references them and does not restate them. What follows is lane
 stewardship: which subsystem owns which need, and what ops-warden does about it.
 
@@ -137,7 +170,7 @@ orientation, and the catalog is the source of truth (`ADR-0001`).
 
 ### Access lane versus access rule
 
-Normative, per `security-layer-model_v0.1` section 8 and assented to in `ADR-0010`:
+Normative, per `security-layer-model_v0.7` §8 and assented to in `ADR-0010`:
 
 - **access lane** — ops-warden and ops-mason. *How* a worker reaches a host.
 - **access rule** — access-engine. *Whether* they may.
@@ -147,7 +180,8 @@ may do something is not an ops-warden question, however it arrives.
 
 Canonical references:
 
-- `net-kingdom/canon/standards/security-layer-model_v0.1.md` (layers, section 5, section 8)
+- `net-kingdom/SECURITY-COMPANION.md` — the operative form; start here
+- `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted; §5 shapes, §6.4 PEP, §8 vocabulary)
 - `net-kingdom/docs/platform-identity-security-architecture.md`
 - `net-kingdom/docs/responsibility-map.md`
 - `wiki/AccessManagementDirective.md` (ops SSH actor model)

SCOPE.md

@@ -85,6 +85,28 @@ cutover, flex-auth publishing the zone-aware pre-sign stance package,
 the owner-driven WP-0015 canon landing, and — newly named — the missing owner front
 doors that keep ops-warden holding interim lanes (secrets-engine, tenant-engine).
 
+### Layer-model conformance (v0.7, accepted)
+
+ops-warden declares **Staff**, **PEP-shaped**, in `INTENT.md` frontmatter and in its
+own voice — `security-layer-model_v0.7` §11. Shipped declaration artifacts, both
+cited in the standard as the estate's reference forms:
+
+| Artifact | Declares | Status |
+| --- | --- | --- |
+| `layer.yaml` | 5 Tooling contacts mapped to §5.1/§5.2/§5.3 shapes + non-Tooling clients so the check is total | shipped; named reference form (§11) |
+| `pep-stance.yaml` | unreachable-engine stance map, total per zone | shipped; registered in statute §13.1 (§6.4 obl. 3) |
+| `scripts/check_layer_conformance.py` | every direct Tooling client maps to a declared shape | shipped; CI-enforced |
+| `tests/test_layer_conformance.py` | the §5.2 no-authority property, and published stance map **equals** shipped default | shipped, 11 tests |
+
+Conformance state under §11: **declared gap** — tracked non-conformance, not
+conformance. Two §5.3 contacts (`VaultCA` signing write, `warden desk` `bao kv put`),
+intended owner `secrets-engine`, registered in statute §13.
+
+Four ops-warden findings have been adopted into the standard: §9.1's two marks
+(`pending` vs `declared-gap`), §5's Tooling scope rule, §6.4 obligation 1's second
+limb, and §13.1's existence. Reviews: `history/2026-08-29-layer-model-v04-review.md`,
+`-v06-review.md`, `-v07-scope-intent-assessment.md`.
+
 ### Issue vs route
 
 ops-warden executes exactly one lane with its own authority and routes/assists the rest.
@@ -156,7 +178,7 @@ superseding ADR, never an in-place edit.
 | `ADR-0007` | Build-stage permissiveness stops at credential disclosure; every lane carries an explicit `risk` grade |
 | `ADR-0008` | A lane's risk grade covers every field its path discloses, not just the field it is named after |
 | `ADR-0009` | Adopt security-zones v0.1 and compile explicit workload membership; PEP failure mode is per zone |
-| `ADR-0010` | ops-warden is Staff — it owns access lanes, never access rules; the direct OpenBao client is a declared engine gap, not an exemption |
+| `ADR-0010` | ops-warden is Staff and PEP-shaped — it owns access lanes, never access rules; the direct OpenBao client is a declared engine gap, not an exemption |
 
 Rules we follow but do not own — NetKingdom canon, the IAM profile, the
 credential-management standard, the-custodian's ADR-001 workplan convention — are
@@ -434,7 +456,7 @@ Downstream: `ops-bridge` (primary), kaizen agents, CI automations, human operato
 
 | Repo | Relationship |
 | --- | --- |
-| `gate-house` | Owns security doctrine, invariants, authority context, and conformance review; ops-warden routes doctrine questions there and references rather than restates them (`ADR-0010`) |
+| `gate-house` | Owns the security layer model, doctrine, invariants, authority context, and conformance review. ops-warden routes doctrine questions there, and the companion routes the estate's *path* questions back to ops-warden (`ADR-0010`) |
 | `net-kingdom` | Canonical security architecture; ops-warden aligns to it |
 | `ops-bridge` | Primary cert_command consumer |
 | `railiance-infra` | Host-side SSH principals and hardening |
@@ -488,6 +510,9 @@ keywords: [access, credential, secret, npm, token, api-key, openbao, key-cape, l
 | `wiki/CredentialRouting.md` | Which subsystem for each credential need |
 | `wiki/WorkloadSecurityPosture.md` | Secret-store posture, workload maturity, and blocker triage |
 | `registry/routing/catalog.yaml` | Machine-readable routing pointer catalog |
+| `net-kingdom/SECURITY-COMPANION.md` | **The estate's operative security rules — start here** |
+| `layer.yaml` | Layer declaration: every Tooling contact and its §5 shape |
+| `pep-stance.yaml` | Unreachable-engine stance map (§6.4); equals shipped behaviour by test |
 | `tenancy.yaml` | Declared tenancy posture (`I1 A1 E0 P n/a R n/a V0`) and why each axis sits where it does |
 | `wiki/NetKingdomSecurityMap.md` | Platform security component map |
 | `examples/warden.production.example.yaml` | Production warden.yaml template |

history/2026-08-29-v07-scope-intent-assessment.md

@@ -0,0 +1,157 @@
+# 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.

workplans/WARDEN-WP-0034-layer-model-v07-conformance.md

@@ -0,0 +1,165 @@
+---
+id: WARDEN-WP-0034
+type: workplan
+title: "Layer model v0.7 conformance — state the deadline, bind the agent boundary, steward the estate's newest rule"
+domain: infotech
+repo: ops-warden
+status: ready
+owner: ops-warden
+topic_slug: netkingdom
+planning_priority: P1
+depends_on_workplans:
+  - WARDEN-WP-0030
+created: "2026-08-29"
+updated: "2026-08-29"
+---
+
+# WARDEN-WP-0034 — Layer model v0.7 conformance
+
+`security-layer-model_v0.7` is **accepted**. ops-warden declared Staff and PEP-shaped,
+shipped the two declaration artifacts the standard now cites as estate reference forms,
+and had four findings adopted into the text between v0.4 and v0.7.
+
+The assessment in `history/2026-08-29-v07-scope-intent-assessment.md` checked every
+v0.7 obligation against shipped code rather than intent. Three gaps survive, plus a
+role the companion assigns that no conformance check will ever catch.
+
+## Why a workplan and not an adhoc
+
+T01 is a `MUST` that is currently unstated. T02 changes an enforcement boundary and
+touches `ADR-0004`. T04 is a cross-repo stewardship commitment against a standard eight
+repositories have yet to adopt. The convention reserves adhocs for low-risk work
+completed directly; none of these qualify.
+
+## Tasks
+
+```task
+id: WARDEN-WP-0034-T01
+status: todo
+priority: high
+```
+
+**State the revocation visibility deadline (§9.7.2, a MUST).**
+
+ops-warden states none, and the honest value is the certificate TTL: **up to 48 hours**.
+A cert issued under an allow remains valid for its full TTL even if the authorizing
+decision is revoked the next minute. There is no CRL, no KRL distribution, and host-side
+`auth_principals` belongs to `railiance-infra`.
+
+Add the deadline to `pep-stance.yaml` as what it is — `adm` 48h / `agt` 24h / `atm` 8h —
+with the mechanism named (TTL expiry, no revocation channel) rather than implied. Assert
+it against the shipped `ActorType` TTL policy by test, the same way the stance map is
+asserted equal to shipped behaviour: a stated deadline free to drift from the code has
+the same defect as a stated stance free to drift.
+
+**Done when:** the deadline is published, test-bound to the TTL policy, and the absence
+of a revocation channel is stated rather than left to inference.
+
+**Not in scope:** shortening it. Whether 48h is acceptable is a joint question with
+`railiance-infra` (KRL distribution) and is T05's to raise, not this task's to decide.
+
+```task
+id: WARDEN-WP-0034-T02
+status: todo
+priority: high
+```
+
+**Bind the agent read-boundary to an issued identity (§3.4 rule 1).**
+
+`ADR-0004`'s boundary triggers on `WARDEN_AGENT_ID` — a variable the agent sets about
+itself. An agent that omits it is not recognised as one. §3.4 rule 1 now requires
+authority to be *issued* per task and attributable to the principal acted for.
+
+The identity exists as of `KEY-WP-0009-T03`: `codex-railiance-platform`, subject
+`service:codex:railiance-platform`, role `coding-agent`, 15-minute lifetime, with
+`railiance-platform` enforcing the OpenBao-side policy.
+
+Key the boundary on the issued identity where one is present; keep `WARDEN_AGENT_ID` as
+a fallback that fails **toward** the boundary, never away from it. State plainly in the
+ADR trail which half is enforced and which is advisory: the OpenBao-side deny is real,
+the ops-warden-side refusal is a courtesy that a determined caller can decline.
+
+**Done when:** an agent presenting the issued identity is recognised without setting
+`WARDEN_AGENT_ID`, the fallback still refuses on `risk: high` lanes, and the
+enforced/advisory split is written down.
+
+**Watch:** do not turn this into ops-warden validating a token — that is verifying an
+identity claim, adjacent to deciding, and `ADR-0002`/§6 both point away from it. Read
+the identity; do not adjudicate it.
+
+```task
+id: WARDEN-WP-0034-T03
+status: todo
+priority: medium
+```
+
+**Derive an emission cadence, or defer it with a reason (§9.6).**
+
+ops-warden's trail is attributive, so cadence is a SHOULD rather than v0.7's MUST for
+load-bearing sources. It has been silent through two reviews, which is the one outcome
+that is not defensible.
+
+Derive a baseline from the existing `audit.jsonl` and signatures log. If the signal is
+too bursty to support a threshold — plausible, since volume is operator-driven — record
+that as the finding with the distribution that shows it, and declare the deferral in
+`pep-stance.yaml`. A measured "no useful baseline" is a result; silence is not.
+
+**Done when:** either a declared cadence with its derivation, or a declared deferral
+carrying the data that justifies it.
+
+```task
+id: WARDEN-WP-0034-T04
+status: todo
+priority: medium
+```
+
+**Answer the question the companion sends the estate here to ask.**
+
+> *"For how to get something done — which lane, which credential, which route — ask
+> `ops-warden`."*
+
+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"* — and eight of fifteen catalogued
+repositories have yet to declare.
+
+Provide the path, not the doctrine (that boundary is `ADR-0010`'s and does not move):
+a routing entry and a short playbook that carry a reader from the companion to the files
+to copy — `layer.yaml`, `pep-stance.yaml`, `check_layer_conformance.py`,
+`test_layer_conformance.py` — and the check to run. The standard already names these in
+§11 and §6.4; what is missing is the route to them.
+
+**Done when:** `warden route find "how do I declare my layer"` resolves, and the
+playbook is reachable from the catalog. **Not** a restatement of the companion — a
+pointer layer, per `ADR-0001`.
+
+```task
+id: WARDEN-WP-0034-T05
+status: todo
+priority: low
+```
+
+**Two things to raise rather than absorb.**
+
+Both are other repositories' to own; ops-warden's obligation is to route them, not to
+fix them (`ADR-0003`, `ADR-0005`).
+
+1. **`ops-mason` has published no stance map.** §13.1's register has one row and the
+   standard says that is itself the finding. `ops-mason` is catalogued PEP-shaped in
+   the same paragraph and is ops-warden's peer lane owner. Offer the reference form;
+   do not write their map.
+2. **The 48-hour replay window from T01.** Once stated, raise with `railiance-infra`
+   whether KRL distribution is worth building, and with `access-engine` whether a
+   decision lifetime shorter than the cert TTL is meaningful when nothing can recall
+   the cert. State the question; let the owners answer.
+
+**Done when:** both are routed with reasoning, and the answers recorded either way —
+including a refusal, which is an equally good answer.
+
+## Related
+
+- `history/2026-08-29-v07-scope-intent-assessment.md` — the gap analysis behind this plan
+- `history/2026-08-29-layer-model-v04-review.md`, `-v06-review.md` — the two prior reviews
+- `security-layer-model_v0.7.md` §3.4, §6.4, §9.6, §9.7, §11, §13.1
+- `net-kingdom/SECURITY-COMPANION.md` v0.2
+- `ADR-0002`, `ADR-0003`, `ADR-0004`, `ADR-0005`, `ADR-0009`, `ADR-0010`