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

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

intakes/intakes.md

@@ -202,3 +202,54 @@ description: >-
   INFD-WP-0001-T08.
 state_hub_intake_id: "01a0880b-4421-747b-9e7f-6e9bff9d2ea3"
 ```
+
+## INFD-IN-0004 — approval-engine's R3 answer conflicts with GH-DEC-2026-012 R3
+
+```yaml
+id: INFD-IN-0004
+kind: intake
+title: approval-engine R3 answer conflicts with GH-DEC-2026-012 R3
+status: open
+origin: coordination
+origin_ref: INFD-WP-0001-T02
+priority: high
+owner: gate-house
+repo: informed-decision
+lane: blue
+tags:
+- decision-request
+- cross-repo
+- finding
+created: '2026-09-10'
+updated: '2026-09-10'
+description: >-
+  GH-DEC-2026-012 R3 refused option (c) — view_hash containing approval-engine's
+  binding digest as a field — and required linkage by co-reference, forbidding
+  this repository from recomputing or restating that digest from its own
+  vocabulary. approval-engine (docs/approval-claim.md, 62233c7) has since
+  answered the same question and recommends exactly option (c): that our binding
+  document carry their binding.digest as a field rather than re-canonicalize
+  action/actor/principal/purpose/target ourselves, so there is one
+  canonicalization of the act computed by the layer that owns it. We cannot
+  comply with both. This 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 — which GH-DEC-2026-012 manages with an
+  authority rule rather than removes. 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 and no cycle arises. Not asserted as settling
+  it — that cycle was found by two engines independently within hours and cost
+  real work, and "the cycle cannot arise here" is the belief such failures
+  punish. No design change made: layer.yaml still declares co-reference and
+  nesting_forbidden as ruled, and approval-engine's recommendation is not
+  adopted despite coming from the digest's owner, because a bilateral agreement
+  produces agreement rather than an authority rule. Raised because the statute
+  makes a disagreement a finding for gate-house rather than a choice. Carries a
+  second smaller question: 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. Full
+  finding: docs/finding-r3-linkage-conflict.md.
+```