diff --git a/workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md b/workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
index 06f4824..d2141ad 100644
--- a/workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
+++ b/workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
@@ -137,6 +137,25 @@ issuer's `/jwks`, checking `iss`, `aud=approval-engine`, expiry, `sub`,
 nowhere in the codebase. Recorded in `docs/keycape-service-registrations.md`.
 T01 stays `progress`.
 
+2026-09-09 follow-up: the operator established `informed-decision`
+(`INFD-WP-0001`) as the owner of the browser-facing approver surface, closing
+the unassigned dependency recorded the previous day. Requirements issued to it
+in `docs/approver-surface-requirements.md`: the two routes an approver surface
+needs, the hard token claims, error/disposition mapping, and the standing
+refusal to expose an inbox listing or a decision. Three items need an owner's
+answer rather than an implementation: (A) the human client's specified
+`allowedScopes` `[openid, approval:approve]` cannot `GET /v1/approvals/{id}`, so
+the surface could submit an entry it was never able to render — we recommend
+adding `approval:read` to the human client over reading through a BFF service
+client, and this needs a key-cape decision; (B) `assurance` is persisted
+verbatim and is the only place `mfaRequired: true` survives into the approval
+record, so key-cape and informed-decision owe it a documented shape; (C)
+`informed-decision`'s `view_hash` has nowhere to ride into an entry, whose body
+is deliberately discarded — v1 correlates by `(approval_id, subject,
+approved_at)` via audit-core, and binding the hash into the entry itself would
+be a gate-house doctrine question before it is a change here. T01 stays
+`progress`; none of these block this repository's half.
+
 ## Harden durable storage and migrations
 
 ```task