coulomb/approval-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Log the T01 approver-evidence work

Browse source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
This commit is contained in:
tegwick 2026-09-09 14:10:31 +02:00
parent 31da1af5e4
commit 92043cfe51
1 changed files with 28 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

28
workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
View file

@ -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