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

Principal is the requesting party, not the approver

Browse source 
informed-decision asked whether its binding.principal and ours name the same
field, since both GH rulings said its slice canonicalizes "two of the five".
They do not: ours is the party on whose behalf the act is performed, taken from
the decision request's subject, while theirs is the approver — which appears
here only as an entry and never in binding. Only target overlaps.

Records the four-role distinction normatively in docs/approval-claim.md and
guards it with a test asserting the act digest is insensitive to the approver
while the approver stays recorded on the entry. Folding approver identity into
the digest would now break view_hash's assumption here rather than silently in
that repository.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QDzGbdDFnVJBxDgdp7RvpH

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2191554@bnt-lap001
Assistant-Session: d69bb7c3-b7b2-41c4-8287-6baef48c0993
This commit is contained in:
tegwick 2026-09-10 22:43:33 +02:00
parent 2fdb01d42a
commit a0a602976e
3 changed files with 81 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -275,6 +275,33 @@ must not be treated as satisfying it. Evidence:
`docs/evidence/2026-09-10-human-control.json`. No production approval or database
migration occurred during these tests.
2026-09-10 (third): `informed-decision` activated GH-DEC-2026-015 — `view_hash`
now carries our `binding.digest` and no longer canonicalizes the act-scope, so
the estate has one canonicalization of the act. They verified our exclusion
condition by running the test themselves rather than taking it on report, and
asked one open question (`principal_role_overlap`). Answered: **the two
`binding.principal` fields are different roles and theirs must stay.** Ours is
the party *on whose behalf* the act is performed, taken from the decision
request's subject; `actor` is who may use the approval; the approver is an entry
and is not in `binding` at all. Only `target` actually overlaps, so the "two of
the five" shorthand now carried in two rulings was wrong about principal.
`docs/approval-claim.md` records the four-role distinction normatively, and
`tests/test_claim_contract.py::test_approver_identity_is_not_in_the_act_digest`
asserts both halves — the digest is insensitive to the approver, and the approver
stays recorded on the entry. It is a regression guard, not a fix: folding
approver identity into our digest would now break their hash loudly here rather
than silently there, which is the narrowing half of the two-sided pinning they
credited on the act-scope. Not added to `layer.yaml`: that file is the
security-layer-model declaration and has no invariant-ledger section.
Also answered their flag that `principal_type: human` is the same shape as the
GH-DEC-2026-013 tenant gap — it is not today (`effectiveTenant` reads a
registration field; the reviewed KeyCape source sets `human` only on the
PKCE/user path, and no registration field supplies it), but the distinction rests
on a source review rather than production proof, which is exactly the native-proof
item T01 still owns. Suite: 156 tests pass. T01 stays `progress`; the remaining
work is unchanged — exact requester/human registration, gated on key-cape
settling the human tenant source, and native issuer proof with a real human flow.
2026-09-10 (second): key-cape reports the `approval-engine-operator` withdrawal
came too late — the client was provisioned and verified in the 2026-09-09
attended custody window, secret in the namespace and wired into a pod. A live