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

Enforce declared human controls at approval binding

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
This commit is contained in:
tegwick 2026-09-10 19:26:12 +02:00
parent a3c94fb241
commit be1a388a84
17 changed files with 441 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/storage-operations.md
View file

@ -60,3 +60,21 @@ 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`.
## Schema v5 — explicit human-control declaration
GH-DEC-2026-016 adds `approvals.human_control`, constrained to 0 or 1, with default
0. Existing objects remain undeclared regardless of recorded approver types;
there is no retrospective declaration or change to their five-field binding
digest. A successor inherits the declaration. Linking an existing successor with
a different declaration conflicts and rolls back the parent transition.
New human-control entries require verified type human at the engine boundary.
The declaration is retained on object/claim and audit events. Claim and consume
also refuse inconsistent persisted human evidence. Tests cover a persistent v4
upgrade and preservation, signed API refusal, quorum and outbox rollback. Take
and verify the existing backup before migration. The old v3 image must not serve
a v5 database; rollback requires the matching pre-migration backup and the
existing single-writer recovery procedure. No live database is migrated by the
source test run.