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
Two rulings landed and both corrected something.
GH-DEC-2026-013 accepted our binding-versus-awareness argument, wrote it into
the record as its §6, and did not change the outcome — it sharpened the defect.
Two different facts share one field named tenant: the act-scope, a property of
the act that our binding slice commits, and the principal's membership, a
property of the person that approval-engine exact-matches. Gate House's
correction stands: a binding slice that must commit the scope being entered
should commit that scope, not borrow a membership claim to stand in for it. Our
schema already does — binding.target IS the act-scope and is inside view_hash —
so no field was added, only a statement (PR-08) and a provenance record (PR-09),
since key-cape emits tenant as a bare string.
key-cape had already implemented registration-bound tenancy on 2026-09-09,
correct under both candidate rulings, so the fail-closed-at-first-use risk that
made us withhold the client strings was already retired. IN-0002 closed. The one
remaining input to T07 is the deployed origin.
GH-DEC-2026-014 granted commitment-only evidence and bounded it. It satisfies
non-alteration and NOT reconstructability, and must not be described otherwise
anywhere. It also corrected our wording of the gap: we wrote that it leaves us
able to erase the content, which understates it. Commitment-only moves integrity
out of our control and leaves availability entirely inside it — the party that
can withhold the content is the party the evidence is about. Limit 3's condition
reduced, not removed.
The grant carries a condition we did not propose and would not have thought of:
the path must assert that committed content exists and where custody sits, so
non-production is a finding attributable to the custodian rather than an
unremarkable blank. A commitment with no assertion that something is being
committed to is indistinguishable from a commitment to nothing. Booked as PR-53,
and marked not-a-reversal-candidate.
Recorded the meta-rule Gate House named, now in its third setting here: unknown
versus absent in the stance map, directory-asserted versus registration-supplied
in the tenant claim, erased versus never held in the evidence path. Wherever a
system reaches one appearance by two routes, the record must say which route.
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
Housekeeping the ruling left behind, plus the one piece of blocked work that was
substantially ours to move.
INFD-IN-0001 closed with its resolution recorded, matching approval-engine's
IN-0002 form. It was still open after GH-DEC-2026-012 answered it.
INFD-IN-0003 and docs/evidence-path-design.md take up O-02, which was sitting in
the blueprint as "mechanism unchosen". Read independence and the local
transactional outbox are settled and not in question. The real question is what
travels, and it is sharper for us than for approval-engine because a
presentation record carries the brief and packet material actually shown to a
human. Three candidates with costs; proposal is commitment-only for Stage 1 —
hashes, principal, timestamps, acks, co-referenced approval id — which
discharges limit 3 and removes our ability to alter the record, while leaving us
able to erase the content. That residual is declared alongside the existing
compromised-surface one rather than papered over.
Deliberately not proposing the full binding document unilaterally: it would put
commercial and personal material into the audit fabric under retention and
export entitlements designed for audit events. That is a meaningful change in
what audit-core holds and is its owner's to accept, not ours to assume. The
third option, a separate evidence store, is refused here because that store has
no owner and inventing one routes around the §16 decision against stronger
archival custody.
Cadence declared and its form argued rather than copied: approval-engine's
heartbeat answer suits genuinely low-volume classes, but ours are mixed —
presentations are one per render, while dispositions and stance applications are
low-volume and are the security-relevant ones. Reconciliation per class as
primary, heartbeat for the low-volume classes. Depends on AUDIT-WP-0009 T04/T06;
declared, not claimed operating.
INFD-IN-0002 files the tenant blocker as a tracked record rather than leaving it
in message threads and a blueprint footnote. T07 and T08 now name their blocking
intakes.
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
T05 written after the ruling rather than before it, which was the point of
gating it. GH-DEC-2026-012 limit 3 did most of the shaping: the evidence copy
must reach audit-core independently of this component, because here the actor
being audited and the evidence source are the same. Booked as four binding
implementation consequences plus O-02, which must be resolved before T08 ships —
"we will add the independent path later" is how limit 3 becomes
limit-3-in-principle.
Other constraints fixed in the blueprint: presentation/ is the only writer of
view_hash; the approval-engine client exposes no validity cache; a fail-closed
outcome is never recorded as an approver's decline, since the human made none;
the assurance shape is cited from key-cape's contract rather than restated so it
cannot drift; and no polling loop may synthesise the inbox approval-engine
refuses to provide.
T06 closed with the SCOPE.md rewrite the ruling unblocked. It carries a "What
this repository does not claim" section, because a scope file listing only
capabilities overstates them: the decision path is not validated while
GH-DEC-2026-010 is open, the residual is not closed, view_hash is not inside the
approval entry, and nothing is deployed.
Two open items block the remainder. O-01, the human token tenant, blocks T07 and
is not ours alone to decide. O-02, the independent evidence path, blocks T08.
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
approval-engine replied to INFD-IN-0001 with docs/approver-surface-requirements.md
(31da1af, 5203f46) and two corrections. Several of my requirements were wrong or
incomplete; revised rather than appended to.
Corrected:
- PR-02 listed only approval:approve. Wrong — the surface also needs
approval:read to fetch what it renders. As drafted it would have shipped a
client able to submit an entry it could never display. That changes a
registration key-cape has already implemented, so it is their call (open
question A).
- NC-03 implied approval-engine refuses non-human approver entries. It does not;
only /consume is principal-restricted, and the operator service client holds
approval:approve. Enforcement of "humans bind, agents draft" is therefore ours
alone, and is auditable via schema v4's entries[].principal_type — never from
the shape of subject_id.
Added:
- PR-04 assurance shape. approval-engine persists it verbatim and accepts an
empty object, so it is the only place MFA survives into the approval record.
Needs auth method, acr/amr, auth_time, agreed with key-cape.
- PR-05 entitlement. A 200 from the engine is not permission to view; we owe
access-engine a check before rendering. Consuming a decision, not making one.
- PR-06 response mapping, including 409 duplicate_approver rendered as SUCCESS
(a browser double-submit is routine and the first entry stands) and 503 as
fail-closed.
- PR-07 and a matching INTENT wrongness condition: never render `approved` as
permission to act. That is a PDP in the browser wearing UI copy.
- L-05, L-06 and EvidenceModel 8b: view_hash cannot ride into the entry — the
POST discards its body by design — so Stage 1 correlates by (approval_id,
subject, approved_at). DoD-3 is satisfied by the triple, not by a stored hash.
PRD open question 1 is answered by construction: there is no inbox endpoint and
there will not be one, so the approvals-inbox shape is foreclosed upstream.
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
Verified the three published hashes reproduce byte for byte before promoting
anything, then moved the schema, canonicalizer and vectors into governed assets.
history/20260909-initial-exploration/ is untouched and stays the provenance
record.
- schemas/, informed_decision/, tests/vectors/ populated; the reference
canonicalizer's ad-hoc __main__ block replaced by a real
`python -m informed_decision` entry point.
- tests/test_canonicalize.py — 20 tests, all green. Published vectors, all four
isolation properties, canonical-form round-trip, key sorting, and a provenance
test asserting the governed fixtures have not drifted from history/.
- docs/specs/EvidenceModel.md — the two hashes, the split and why it exists, the
four isolation properties, the presentation record, the bundle, and the
relationship to audit-core.
- pyproject.toml, Makefile.
One test of mine was wrong on first run: it scanned for ", " to assert no
insignificant whitespace, which fires on prose inside a brief. Replaced with a
canonical round-trip comparison, which is the property actually meant. The
canonicalizer was correct.
EvidenceModel leads with what the model does NOT claim — no proof of
comprehension, no proof of reading (deliberately, since the alternative is
surveillance), no survival of a compromised surface, and audit-core's inherited
bound that a hash chain cannot prove a record was never sent.
T06 stays progress: the SCOPE.md rewrite is gated on the T02 ruling.
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
T02 — intake INFD-IN-0001 filed with gate-house and messages sent to gate-house,
key-cape and approval-engine. Status progress; it now waits on an external
ruling. key-cape was told explicitly why T07 is not answering KEY-WP-0013-T02
yet — a placeholder callback URI would either fail closed or register an origin
no component owns — and given the token shape to check now rather than at T07.
T03 — ProductRequirementsDocument.md. 30 requirements, each traced to a GOAL.md
DoD item, an INTENT principle or wrongness condition, a state-transition guard,
or a named external contract, and each with an observable pass condition.
Anti-requirements are stated as testable absences: no dwell timers, no attention
analytics, no dark patterns, no auto-approval, no approval-state caching, no
authorization endpoint. Four limitations are recorded up front, including that
escalate without a mandate graph is forwarding and that view_hash is computed by
the renderer.
T04 — UseCaseCatalog.md. L0-L5 with counterparties, plus ten negative cases
bound to guards and isolation vectors. Each case records the constraint it
places on the shared schema, so scale invariance is testable rather than
asserted. Closes with the four changes that would fork the object.
T05 and T07 remain gated on the ruling. T06 is independent and is next.
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
