diff --git a/history/2026-08-11-delegation-surface-assessment.md b/history/2026-08-11-delegation-surface-assessment.md
index c2004ed..43199d0 100644
--- a/history/2026-08-11-delegation-surface-assessment.md
+++ b/history/2026-08-11-delegation-surface-assessment.md
@@ -41,23 +41,40 @@ Consequence: an absorbed need is indistinguishable from a designed one. Ownershi
 drift is invisible by construction, which is exactly the failure mode the directive
 targets.
 
-## 3. Drafted classification of the eleven
+## 3. Classification of the eleven (revised on inspection, founder review 2026-08-11)
 
-Not authoritative — architecture judgement belongs to the founder (WP-0030 T02).
+A first draft sorted by *subsystem* — tenant lanes to tenant-engine, workload lanes to
+secrets-engine. Reading the entries showed that is the wrong axis. Nine of the eleven
+share one `auth_method` ("caller's own OpenBao token" via operator OIDC or a
+`workload-kv-read-*` policy) and one `fetch_command` shape
+(`bao kv get -field=X <path>`). No owner procedure is duplicated in those. Contrast
+`whynot-design-npm-publish` — npm config plus token injection into a specific tool, a
+*procedure*, which is why WP-0019 handed it to secrets-engine.
 
-| Lane | Draft reading | Intended owner / blocker |
+**Test applied: owner-specific procedure or lifecycle → interim. Generic KV read →
+thin wrapper, arguably permanent.**
+
+### Interim (5) — classified
+
+| Lane | Intended owner | Blocked on |
 | --- | --- | --- |
-| `key-cape-oidc-login` | **Permanent** | Login is key-cape's; the proxy is caller convenience, not custody |
-| `openbao-api-key` | **Permanent (by design)** | Generic escape hatch for any OpenBao path; a catch-all, not a lane |
-| `binky-company-email-imap` | Interim | **tenant-engine** — WP-0028 defined the tenant custody pattern; no tenant front door executes it |
-| `binky-qonto-api` | Interim | **tenant-engine** — same |
-| `rapp-qonto-keycape-client` | Interim | **tenant-engine** / key-cape — tenant workload client credential |
-| `issue-core-ingestion-api-key` | Interim | **secrets-engine** — same shape WP-0019 closed for npm publish |
-| `openrouter-llm-connect` | Interim | **secrets-engine** — high-risk provider key |
-| `reuse-surface-hub-write-token` | Interim | **secrets-engine** |
-| `railiance-backup-offsite-lane` | Interim | **secrets-engine** / railiance-platform |
-| `forgejo-admin-api-token` | Interim | **secrets-engine** |
-| `agent-harness-forgejo-deploy` | Interim | **secrets-engine** |
+| `rapp-qonto-keycape-client` | key-cape | `client_secret_basic` exchange is a key-cape procedure; rotation already `automatable: true` |
+| `binky-company-email-imap` | tenant-engine | `tenants/binky/...` custody, rotation owned by `binky-control` — split lifecycle |
+| `binky-qonto-api` | tenant-engine | Same split |
+| `railiance-backup-offsite-lane` | railiance-platform | Rotation is `re-establish`, a procedure ops-warden only describes |
+| `agent-harness-forgejo-deploy` | railiance-platform / agent-harness | `re-establish` + alternative host-local key path |
+
+### Held (6) — pending secrets-engine
+
+`openbao-api-key`, `key-cape-oidc-login`, `issue-core-ingestion-api-key`,
+`reuse-surface-hub-write-token`, `openrouter-llm-connect`, `forgejo-admin-api-token`.
+
+Permanent **only if** `secrets-engine exec` stays per-lane and provisioned. If it
+generalizes over arbitrary OpenBao lanes, all six become interim with secrets-engine as
+intended owner. Asked directly (msg `7d55d332`). For three of them
+(`issue-core-*`, `reuse-surface-*`, `openrouter-llm-connect`) production never touches
+the proxy at all — External Secrets delivers the value and the proxy serves operator
+verification only, which weakens the case that a front door is missing.
 
 **No lane names `user-engine` as owner.** It appears only as a *consumer* inside
 `coulomb-social-runtime-env` (route-only, owned by railiance-platform), whose rotation
diff --git a/workplans/WARDEN-WP-0030-delegation-register.md b/workplans/WARDEN-WP-0030-delegation-register.md
index c0ec772..6e13a4a 100644
--- a/workplans/WARDEN-WP-0030-delegation-register.md
+++ b/workplans/WARDEN-WP-0030-delegation-register.md
@@ -120,8 +120,8 @@ delegation:
 
 Backfill all 24 entries. `exec_owner` lanes become `mode: native`.
 `ssh-cert-host-access` becomes `mode: permanent` (ops-warden's own lane). The
-eleven undelegated proxies get a **drafted** classification plus intended owner,
-flagged in the workplan for founder review rather than asserted as settled.
+eleven undelegated proxies are classified per the founder review below — five
+`interim` now, six held pending secrets-engine's answer.
 
 ### T03 — `warden route gaps` + conformance test
 
@@ -178,22 +178,56 @@ fleet-visible capability gap.
 - [ ] Founder has reviewed the interim/permanent classification of the eleven
 - [ ] Register delivered to the named owner repos
 
-## Open question for the founder
+## Classification of the eleven (founder review, 2026-08-11)
 
-The eleven undelegated proxies are: `openbao-api-key`, `key-cape-oidc-login`,
-`issue-core-ingestion-api-key`, `reuse-surface-hub-write-token`,
-`openrouter-llm-connect`, `railiance-backup-offsite-lane`, `forgejo-admin-api-token`,
-`binky-company-email-imap`, `binky-qonto-api`, `rapp-qonto-keycape-client`,
-`agent-harness-forgejo-deploy`.
+### The test
+
+An initial draft sorted by *subsystem* (tenant lanes → tenant-engine, workload lanes →
+secrets-engine). Inspecting the entries showed that is the wrong axis. Nine of the
+eleven share one `auth_method` — "caller's own OpenBao token" (operator OIDC via
+key-cape, or a `workload-kv-read-*` policy) — and one `fetch_command` shape,
+`bao kv get -field=X <path>`. No owner procedure is duplicated there. Contrast
+`whynot-design-npm-publish`, which needs npm config and token injection into a specific
+tool; that is a *procedure*, which is why WP-0019 handed it to secrets-engine.
+
+**Test: owner-specific procedure or lifecycle → `interim`. Generic KV read →
+ops-warden's thin wrapper is arguably `permanent`.**
+
+### Interim — classify now (5)
+
+| Lane | `intended_owner` | `blocked_on` |
+| --- | --- | --- |
+| `rapp-qonto-keycape-client` | key-cape | `client_secret_basic` exchange is a key-cape protocol procedure, not a KV read; rotation already `automatable: true`, so key-cape could front it today |
+| `binky-company-email-imap` | tenant-engine | Custody at `tenants/binky/...` but rotation owner is `binky-control` — split lifecycle, no front door reconciling it |
+| `binky-qonto-api` | tenant-engine | Same split, same tenant |
+| `railiance-backup-offsite-lane` | railiance-platform | Rotation is `re-establish`, a multi-step procedure ops-warden only describes |
+| `agent-harness-forgejo-deploy` | railiance-platform / agent-harness | `re-establish` plus an alternative host-local key path; two ways in, neither owner-fronted |
+
+### Held pending secrets-engine (6)
+
+`openbao-api-key`, `key-cape-oidc-login`, `issue-core-ingestion-api-key`,
+`reuse-surface-hub-write-token`, `openrouter-llm-connect`, `forgejo-admin-api-token`.
+
+These pass the test as `permanent` **only if `secrets-engine exec` stays per-lane and
+provisioned.** If secrets-engine intends `exec --catalog <id>` to generalize over
+arbitrary OpenBao lanes, the thin-wrapper argument collapses and all six become
+`interim` with `intended_owner: secrets-engine` — ops-warden would then be duplicating
+a front door the owner provides.
+
+Asked directly (msg `7d55d332`, 2026-08-11): generic or per-lane; if generic, is it
+near-term enough to mark now; and are there lanes they would decline, so those can be
+marked permanent with the owner's position on record rather than ops-warden's inference.
+
+Supporting detail: for `issue-core-ingestion-api-key`, `reuse-surface-hub-write-token`
+and `openrouter-llm-connect`, **production never touches the proxy** — External Secrets
+syncs the value into the cluster and the proxy exists for operator verification and
+debugging. That weakens the case that they represent a missing front door at all.
+
+**Do not backfill these six until the answer arrives.** A lane wrongly marked
+`permanent` bakes in exactly the ownership drift this register exists to catch.
+
+### user-engine
 
-Draft reading, for review in T02: `key-cape-oidc-login` is **permanent** (login is
-key-cape's and the proxy is convenience, not custody). `openbao-api-key` is the
-generic escape hatch and is arguably permanent-by-design. The two `binky-*` tenant
-lanes and `rapp-qonto-keycape-client` look like **tenant-engine** gaps (WP-0028
-defined the custody pattern; no tenant front door executes it). The workload secret
-lanes — `issue-core-*`, `openrouter-llm-connect`, `reuse-surface-*`,
-`railiance-backup-*`, `forgejo-admin-*`, `agent-harness-forgejo-deploy` — look like
-**secrets-engine** gaps of the same shape WP-0019 already closed for npm publish.
 No lane names **user-engine** as owner — it appears only as a consumer inside
 `coulomb-social-runtime-env` (`USER_ENGINE_PROXY_SECRET`, rotated at
 `user-engine/user-engine-runtime`). Whether user-engine should front that lane itself