From 92043cfe5189d2e4921941c07153202f8797d7fd Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 9 Sep 2026 14:10:31 +0200 Subject: [PATCH] Log the T01 approver-evidence work Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe Assistant: claude-code Assistant-Model: opus Assistant-Process: 1275879@bnt-lap001 Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad --- ...duction-readiness-and-consumer-adoption.md | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) 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