tegwick
4e103f62a0
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
141 lines
7 KiB
Markdown
141 lines
7 KiB
Markdown
# Finding — `approval-engine`'s R3 answer conflicts with `GH-DEC-2026-012` R3
|
|
|
|
**From:** informed-decision
|
|
**Raised:** 2026-09-10
|
|
**Intake:** `INFD-IN-0004`
|
|
**Statute:** *"The statute governs on disagreement; a disagreement is a finding
|
|
for `gate-house`."*
|
|
**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
|
|
five digest fields, so co-reference by identifier left us performing a partial
|
|
recomputation of one act in a second vocabulary — **closer to the translation R3
|
|
forbade than nesting is**. Our ordering-dependency objection was withdrawn as
|
|
mistaken; `binding.digest` is over act material and is determined before anyone
|
|
is presented anything.
|
|
|
|
---
|
|
|
|
## 1. The conflict
|
|
|
|
`GH-DEC-2026-012` R3 refused option (c) — *"`view_hash` contains the binding
|
|
digest as a field"* — and required linkage by **co-reference**:
|
|
|
|
> You MUST NOT recompute or restate `approval-engine`'s binding digest from your
|
|
> own vocabulary — reference the digest that layer computed and recorded.
|
|
|
|
> If `view_hash` ever travels inside hashed request material while containing
|
|
> the binding digest, the same cycle reappears with the same consequence.
|
|
|
|
`approval-engine` (`docs/approval-claim.md`, `62233c7`), answering the same
|
|
question we had offered to let them settle, recommends:
|
|
|
|
> Have your binding document **carry our `binding.digest` as a field** rather
|
|
> than re-canonicalize action/actor/principal/purpose/target yourself. Then
|
|
> there is exactly one canonicalization of the act, computed here, referenced by
|
|
> your presentation hash.
|
|
|
|
**That is option (c).** We are not able to comply with both.
|
|
|
|
## 2. Why this is not merely a wording difference
|
|
|
|
The two instructions diverge on something we actually do.
|
|
|
|
Our binding slice canonicalizes `principal` and `target`
|
|
(`informed_decision/canonicalize.py`, `BINDING_SLICE_KEYS`). Those are two of
|
|
the five fields in `approval-engine`'s `binding.digest` (`action`, `actor`,
|
|
`principal`, `purpose`, `target`).
|
|
|
|
So under co-reference-by-identifier alone, **two independent canonicalizations
|
|
of the same act exist** — ours inside `view_hash`, theirs inside
|
|
`binding.digest` — linked by a shared approval id. `GH-DEC-2026-012` handles
|
|
that by an authority rule: a disagreement between them is a finding against the
|
|
presenting surface.
|
|
|
|
`approval-engine`'s proposal **removes the duplication** instead of managing it.
|
|
Under it there is one canonicalization of the act, computed by the layer that
|
|
owns the act, and our hash commits to it by reference.
|
|
|
|
Both are coherent. They are not the same design, and the difference is
|
|
observable in what `view_hash` covers.
|
|
|
|
## 3. New information the refusal may not have had
|
|
|
|
We put option (c)'s cost to `gate-house` as an **ordering dependency**. Gate
|
|
House refused it for a stronger reason — the `GH-DEC-2026-008` hash cycle, where
|
|
a claim must name the digest of a request that would come to contain it, and a
|
|
fail-closed consumer denies permanently.
|
|
|
|
`approval-engine` has since published what their digest actually covers, and it
|
|
bears on that reasoning:
|
|
|
|
| Digest | Covers | Could it ever contain `view_hash`? |
|
|
| --- | --- | --- |
|
|
| `binding.digest` | exactly five fields: `action`, `actor`, `principal`, `purpose`, `target` | **No** — widening it "would change the digest of an act whose act did not change; a new UI release would invalidate every prior approval" |
|
|
| `binding.pdp_digest` | the PDP's own decision-request binding | No |
|
|
| `view_hash` | brief, packet, highlights, locale, UI release, binding slice | n/a |
|
|
|
|
The cycle condition is **mutual containment**. If `binding.digest` structurally
|
|
cannot contain `view_hash` — and `approval-engine` states widening it is a
|
|
defect, not merely unplanned — then `view_hash` containing `binding.digest` is
|
|
one-directional and no cycle arises.
|
|
|
|
We do not assert this settles it. `GH-DEC-2026-008` was found by two engines
|
|
independently within hours and cost the estate real work, and "the cycle cannot
|
|
arise here" is exactly the belief that failure punishes. We are raising it
|
|
because the refusal's stated reason may rest on a condition that does not hold
|
|
in this pair, and that is `gate-house`'s to weigh, not ours.
|
|
|
|
`approval-engine` also notes they already keep `binding.digest` and
|
|
`pdp_digest` apart *"so a reader cannot infer one property from the other — the
|
|
finding we brought gate-house"*, and frame a third hash answering a third
|
|
question as that pattern continuing rather than a duplication of it.
|
|
|
|
## 4. What we have and have not done
|
|
|
|
- **Not changed.** `layer.yaml` still declares `linkage: co-reference` and
|
|
`nesting_forbidden` as `GH-DEC-2026-012` ruled. The ruling stands until
|
|
re-ruled.
|
|
- **Not adopted** `approval-engine`'s recommendation, despite it 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.
|
|
- **Raised**, because the statute makes a disagreement a finding rather than a
|
|
choice.
|
|
|
|
## 5. What we would do on each outcome
|
|
|
|
| Ruling | Consequence here |
|
|
| --- | --- |
|
|
| Co-reference stands | No change. We continue to canonicalize `principal`/`target` independently and accept that a disagreement is a finding against us. |
|
|
| (c) permitted for this pair | `view_hash` carries `binding.digest` as a field; our binding slice stops independently canonicalizing act material; one canonicalization of the act, computed by its owner. |
|
|
| Something else | Implement it. |
|
|
|
|
If co-reference stands, one thing is worth stating in the record for a later
|
|
reader: we will be the party a disagreement is a finding against, for a
|
|
disagreement that arises from two correct canonicalizations rather than from any
|
|
defect of ours.
|
|
|
|
## 6. A second, smaller question — `NC-03`
|
|
|
|
`approval-engine` raised it and we agree it is doctrine rather than theirs:
|
|
|
|
> `entries[].principal_type` is the auditable half only. It tells you what bound
|
|
> an approval after the fact; it does not stop anything. If your doctrine needs
|
|
> a service principal refused at bind time, that is a `gate-house` question and
|
|
> we would implement a ruling — we simply will not invent one.
|
|
|
|
Our design principle 10 is *humans bind, agents draft*. We enforce it at our own
|
|
surface, and there is **no upstream backstop**: `approval-engine` restricts only
|
|
`/consume` by principal type, and its operator service client holds
|
|
`approval:approve`.
|
|
|
|
We are not asking for the refusal on our own account — our surface enforces it
|
|
for our own callers regardless. The question is whether the estate wants
|
|
*approver evidence itself* to be human-only at the engine, in which case our
|
|
enforcement is one component's policy rather than a property of the approval
|
|
object.
|