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 d2141ad..f7127d5 100644
--- a/workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
+++ b/workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
@@ -156,6 +156,34 @@ 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.
 
+2026-09-09 (second): took T01 as far as this repository can reach. Writing the
+approver-surface requirements exposed a gap in T01's own "approver evidence"
+clause: an entry recorded `subject_id`, `assurance` and `evidence_ref` but
+nothing about *what kind of principal* bound the approval, and `subject_id` is a
+naming convention rather than a verified claim. `/entries` is not restricted by
+principal type — only `/consume` is, to service/agent — and the
+`approval-engine-operator` client holds `approval:approve`, so a service
+principal can supply approver evidence today and was until now indistinguishable
+from a human in the evidence chain. Whether a non-human may approve at all is
+approval doctrine and belongs to `gate-house`; making it legible is ours.
+Schema v4 adds `entries.principal_type`, populated only from the verified token,
+surfaced on the object and on the audit evidence path but deliberately not on
+the least-disclosure claim. Legacy entries stay `null` rather than being
+back-filled into a `human` claim nobody made — the same reasoning as `pdp_path`
+under `GH-DEC-2026-008`. Tests:
+`test_entry_records_the_verified_principal_type`,
+`test_non_human_approver_is_recorded_as_such`,
+`test_v3_entries_migrate_to_v4_without_inventing_a_principal_type`, and the
+v2 migration test now asserts the current version rather than a hard-coded 3.
+124 tests pass. The existing `migrate` initContainer in
+`deploy/approval-engine.yaml` covers the upgrade, but the manifest's pinned
+image digest predates v4 — this change ships only with a re-pinned release
+image. Also corrected two errors in the requirements issued earlier today: agent
+tokens are *not* barred from `approval:approve`, and an empty `assurance` object
+is accepted rather than refused. T01 remains `progress`: what is left is
+key-cape owning the registrations, credential custody from railiance-platform,
+and the open scope question (A) above — none of them reachable from here.
+
 ## Harden durable storage and migrations
 
 ```task