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

Raise INFD-IN-0004: approval-engine's R3 answer conflicts with the ruling

Browse source 
approval-engine answered R3 and recommends exactly the option GH-DEC-2026-012
refused: that our binding document carry their binding.digest as a field rather
than re-canonicalize action/actor/principal/purpose/target ourselves. We cannot
comply with both, so this is raised as a finding rather than resolved.

It is not a wording difference. Our binding slice canonicalizes principal and
target, two of the five fields in their digest, so co-reference by identifier
alone leaves two independent canonicalizations of one act linked by a shared id.
GH-DEC-2026-012 manages that with an authority rule; approval-engine's proposal
removes it. Both are coherent and they are not the same design.

New information the refusal may not have had: their digest covers exactly five
act fields, and they state that widening it to cover presentation would be a
defect since a new UI release would invalidate every prior approval. The
GH-DEC-2026-008 cycle condition is mutual containment, so if their digest
structurally cannot contain view_hash the containment is one-directional. Not
asserted as settling it — that cycle was found by two engines independently
within hours, and "the cycle cannot arise here" is the belief such failures
punish.

Deliberately not adopted, despite coming from the layer that owns the digest and
despite our having offered to let them settle R3. Gate House was right that a
bilateral agreement produces agreement rather than an authority rule, and that
applies to this one too. layer.yaml is unchanged and carries a
linkage_under_review marker rather than a silent edit.

Also carries the smaller doctrine question approval-engine handed on: whether
approver evidence should be human-only at the engine, since
entries[].principal_type is auditable after the fact and stops nothing, and
there is no upstream backstop for humans-bind-agents-draft.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
This commit is contained in:
tegwick 2026-09-10 13:59:52 +02:00
parent 242168d5fb
commit 3a7391fe63
4 changed files with 214 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

28
docs/specs/EvidenceModel.md
View file

@ -183,8 +183,32 @@ binding". They cover different material: the approval digest exists with no
human in the loop; `view_hash` additionally covers brief, packet, highlights,
locale and UI release.
Until ruled, this repository computes `view_hash` and **asserts no relationship**
between the two. Three candidate outcomes and their costs are set out in
**Ruled `GH-DEC-2026-012` R3, and now re-opened as `INFD-IN-0004`.** The ruling:
distinct attestations with an authority rule — the binding digest is
authoritative for what the request *is*, `view_hash` for what was *shown*,
neither substitutable, and a disagreement between them is a finding against the
presenting surface rather than a fact about the request. Linkage by
co-reference, not nesting.
`approval-engine` has since published what its digests actually cover
(`docs/approval-claim.md`) and recommends the opposite linkage — that our
binding document carry their `binding.digest` as a field, which is the option
`GH-DEC-2026-012` refused. Their reason is the stronger version of the risk we
raised: our binding slice canonicalizes `principal` and `target`, two of their
five digest fields, so co-reference by identifier alone leaves **two
independent canonicalizations of one act** rather than removing the duplication.
Raised as a finding rather than resolved bilaterally
(`docs/finding-r3-linkage-conflict.md`). **The ruling stands and nothing has
changed here pending a re-ruling.**
For reference, three hashes answering three questions:
| Hash | Owner | Covers | Answers |
| --- | --- | --- | --- |
| `binding.digest` | `approval-engine` | `action`, `actor`, `principal`, `purpose`, `target` | which **act** is approved |
| `binding.pdp_digest` | `approval-engine` | the PDP's decision-request binding | which **decision request** |
| `view_hash` | here | brief, packet, highlights, locale, UI release, binding slice | what a **person was shown** | Three candidate outcomes and their costs are set out in
`docs/gate-house-decision-request-layer-placement.md` §2 R3. The outcome to be
avoided is both digests shipping with no stated authority rule, leaving the
estate with two canonicalizations of one act.