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

Hold the pinned image against the repository's schema

Browse source 
Schema v4 gave the deployment a silent drift surface: the pinned pair is
self-consistent, migrating to 3 and serving 3, while this repository has
moved to 4. That reads as healthy, which makes it worse than an error —
the failure is the assumption that the deployment records approver
principal type.

Document v4 in storage-operations, state in the deploy runbook that the
pin predates it, and add a test that requires the statement whenever the
release record's schema version differs from this repository's. Verified
to fail when the acknowledgement is removed.

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:38:21 +02:00
parent 92043cfe51
commit fec4eaeb1b
4 changed files with 88 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/storage-operations.md
View file

@ -42,3 +42,21 @@ PDP path, and inferring the declaration from an incidental digest would
manufacture a statement nobody made. Such approvals stay usable by consumers in
this engine's own vocabulary and are simply not usable on the PDP path — which
is the ruling's intended cost, not a migration defect.
## Schema v4 — recorded approver principal type
`entries.principal_type` (TEXT, nullable) records what kind of principal bound
an approval, taken only from the verified token. Migration is the usual additive
`ALTER TABLE`; run `approval-engine migrate` before a production start, which
refuses an unmigrated store.
Legacy entries stay `NULL` and are **not** back-filled — the same reasoning as
`pdp_path` in v3. An entry written before this column existed carries no
verified statement about the principal that made it, and reading `user:`-shaped
`subject_id` values as `human` would manufacture approver evidence nobody
presented. A `NULL` here means *unclassified*, never *human*.
Downgrade is not supported: an older server refuses the store on the version
check rather than reading the column, which is the intended direction. Restore
from a v4 backup onto a v3 release requires re-pinning forward, not editing
`user_version`.