Activate nesting per GH-DEC-2026-015: view_hash carries binding.digest

approval-engine met the condition. Verified here rather than taken on report:
their docs/approval-claim.md carries "Presentation exclusion — GH-DEC-2026-015
§4" in normative language, and I ran
tests/test_claim_contract.py::test_presentation_changes_cannot_change_the_approved_act
myself — 1 passed. That test pins the digest input set from BOTH sides, and the
narrowing half is what makes it real: without it a digest over four fields, or
over a constant, would pass the widening half perfectly.

view_hash now carries binding.digest and the act-scope is no longer
independently canonicalized here, so the act has exactly one canonicalization
computed by the layer that owns it. approval_binding_digest is validated for
shape and refused without its approval id — it is carried, never computed.

The three published vectors are unchanged: they do not carry the new key, so
pick omits it. Asserted, not assumed.

The cycle condition did not disappear, its protection moved — from refusing
nesting to approval-engine's normative exclusion. layer.yaml carries it as
cycle_condition with a test, so a future widening meets a rule rather than
silence.

One thing not assumed. Both gate-house and approval-engine said our binding
slice canonicalizes principal and target, two of their five fields. target
plainly is act material and is now dropped. But their principal is the party ON
WHOSE BEHALF the approval was issued, while ours is the person being BOUND — the
approver. Different roles, and dropping ours would remove who was shown this
from view_hash and gut the promise. Kept it, declared principal_role_overlap
open in layer.yaml, tested that changing the approver still moves view_hash, and
raised it rather than silently resolving it either way.

L0/L2 are unaffected: with no approval there is no digest to defer to, and
test_act_scope_still_binds_when_there_is_no_carried_digest pins that.

100 tests pass.

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

docs/finding-r3-linkage-conflict.md

@@ -5,10 +5,10 @@
 **Intake:** `INFD-IN-0004`
 **Statute:** *"The statute governs on disagreement; a disagreement is a finding
 for `gate-house`."*
-**Status:** **Ruled `GH-DEC-2026-015` — nesting permitted for this pair,
-conditioned and not yet active.** `layer.yaml` remains unchanged: co-reference
-stays in force until `approval-engine` states its presentation exclusion as
-normative and tested. This repository does not activate on its own initiative.
+**Status:** **Closed — ruled `GH-DEC-2026-015`, condition met, activated
+2026-09-10.** `view_hash` carries `binding.digest`; the act-scope is no longer
+independently canonicalized here. Condition verified locally, not taken on
+report. `layer.yaml` records the evidence and the surviving `cycle_condition`.
 
 Gate House reversed itself, and gave the real ground rather than the one we
 argued: our binding slice canonicalizes `principal` and `target`, two of the

docs/specs/EvidenceModel.md

@@ -211,12 +211,34 @@ recomputation of one act in a second vocabulary* — **closer to the translation
 R3 forbade than nesting is**. Nesting removes the duplication; co-reference
 manages it.
 
-**The permission is conditioned and not yet active.** It activates when
-`approval-engine` states its presentation exclusion as **normative and tested**
-rather than as design intent — our own A-17 correction applied to gate-house's
-permission, since the distinguishing case is someone widening the digest and
-that case is unobservable until approvals start failing. Co-reference remains in
-force until then, and this repository does not activate on its own initiative.
+**Activated 2026-09-10.** `approval-engine` met the condition and we verified it
+here rather than taking it on report: their `docs/approval-claim.md` carries
+*"Presentation exclusion — GH-DEC-2026-015 §4"* in normative language, and
+`test_presentation_changes_cannot_change_the_approved_act` pins the input set
+from **both** sides — widening (presentation material leaves the digest
+unchanged) *and* narrowing (each of the five act fields changes it). The
+narrowing half is what makes it real: without it, a digest over four fields, or
+over a constant, would pass the widening half perfectly. Run and confirmed
+passing.
+
+So `view_hash` now **carries** `binding.digest`, and the act-scope is no longer
+independently canonicalized here. The act has exactly one canonicalization,
+computed by the layer that owns it, and `view_hash` means *this person was shown
+this presentation **of this act***.
+
+**The cycle condition did not go away — its protection moved.** It is no longer
+enforced by refusing nesting but by `approval-engine`'s normative exclusion:
+containment stays one-directional because `binding.digest` must never cover
+presentation material. If that exclusion is relaxed, this linkage must be
+revisited *before* the widening ships. `layer.yaml` carries it as
+`cycle_condition` so a future widening meets a rule rather than silence.
+
+**One thing we did not assume.** `approval-engine`'s `principal` is the party
+*on whose behalf* the approval was issued; ours is the person being **bound** —
+the approver. Different roles. Dropping ours on the strength of "the digest
+covers principal" would remove *who was shown this* from `view_hash` and gut the
+promise. We kept it, declared the overlap `open` in `layer.yaml`, and raised it
+with `approval-engine`. If the two are the same field, ours drops too.
 
 Our ordering-dependency objection to option (c) was **withdrawn as mistaken**
 and recorded as withdrawn: `binding.digest` is over act material, determined